从程序员到人工智能时代开发者
From Coder to AI-Era Developer
版权所有 © 2025 Addy Osmani。保留所有权利。
Copyright © 2025 Addy Osmani. All rights reserved.
美国印刷。
Printed in the United States of America.
由O'Reilly Media, Inc.出版,地址:141 Stony Circle, Suite 195, Santa Rosa, CA 95401。
Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401.
O'Reilly 出版的图书可用于教育、商业或销售推广用途。大多数图书也提供在线版本(http://oreilly.com)。欲了解更多信息,请联系我们的企业/机构销售部门:800-998-9938 或corporate@oreilly.com。
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.
有关发行详情,请访问http://oreilly.com/catalog/errata.csp?isbn=9798341634756 。
See http://oreilly.com/catalog/errata.csp?isbn=9798341634756 for release details.
O'Reilly 标志是 O'Reilly Media, Inc. 的注册商标。《超越 Vibe Coding》、封面图片及相关商业外观均为 O'Reilly Media, Inc. 的商标。
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Beyond Vibe Coding, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
本文所表达的观点仅代表作者个人观点,并不代表出版商的观点。尽管出版商和作者已尽力确保本文所含信息和说明的准确性,但出版商和作者对任何错误或遗漏概不负责,包括但不限于因使用或依赖本文而造成的任何损失。使用本文所含信息和说明的风险由您自行承担。如果本文包含或描述的任何代码示例或其他技术受开源许可或其他知识产权的约束,您有责任确保您的使用符合此类许可和/或权利。
The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
本书并非法律建议。如有法律需求,请咨询合格的专业人士。
This book is not intended as legal advice. Please consult a qualified professional if you require legal advice.
979-8-341-63475-6
979-8-341-63475-6
大型综合指数
LSI
我们正处于软件构建方式的深刻变革之中。专业氛围编码——即与人工智能协作创建软件的艺术——正在将开发人员从代码工匠转变为产品远见者和统筹者。
We’re in the midst of a profound shift in how software is built. Professional vibe coding—the art of collaborating with AI to create software—is transforming developers from code artisans into product visionaries and orchestrators.
Vibe 编码的核心在于利用人工智能的强大功能来处理繁重的编码工作,使开发者能够更专注于创意、设计和高层次的问题解决。正如Andrej Karpathy 所说,这就像“忘记代码的存在”,只需构建——描述你的需求,然后让人工智能填充实现细节。这可以带来数量级的生产力提升,使传说中的“10 倍工程师”成为 100 倍的现实。
Vibe coding is about leveraging AI’s prowess to handle the heavy lifting of coding, allowing developers to focus more on ideas, design, and high-level problem solving. As Andrej Karpathy quipped, it’s like “forget[ting] the code even exists” and simply building—describing what you need and letting the AI fill in the implementation details. This can lead to order-of-magnitude productivity gains, making the mythical “10x engineer” potentially a 100x reality.
本书面向三类主要读者。第一类是经验丰富的开发人员和工程领导者,他们希望扩大自身的影响力。如果您从事编码多年,并感到重复性工作带来的负担,本书将向您展示如何将繁琐的工作委托给人工智能,同时提升您作为架构师和战略家的角色。您将学会如何在不牺牲职业生涯中积累的质量标准的前提下,更快地构建产品。
This book is written for three key audiences. The first is experienced developers and engineering leaders who want to multiply their impact. If you’ve been coding for years and feel the weight of repetitive tasks, this book will show you how to delegate the mundane to AI while elevating your role to architect and strategist. You’ll learn to build faster without sacrificing the quality standards you’ve developed over your career.
其次,本书面向那些将代码视为实现目标的手段而非目标本身的产品型工程师。如果您正苦于构想与实现之间的鸿沟,Vibe 编码可以显著缩短这一距离。您将学会如何快速构建原型、迭代并发布产品,而这些如果采用传统方法则需要数月时间。
Second, this book serves product-minded engineers who see code as a means to an end rather than an end itself. If you’re frustrated by the gap between having a vision and implementing it, vibe coding can dramatically compress that distance. You’ll discover how to rapidly prototype, iterate, and ship products that would have taken months with traditional approaches.
我发现人工智能工具最违反直觉的一点是:它们对经验丰富的开发者比对新手更有帮助。这似乎本末倒置——人工智能难道不应该让编程大众化吗?
Here’s the most counterintuitive thing I’ve discovered about AI tools: they help experienced developers more than beginners. This seems backward—shouldn’t AI democratize coding?
事实上,人工智能就像团队里有个非常有热情的新手开发人员。他们能快速编写代码,但需要持续的监督和纠正。你了解得越多,就越能更好地指导他们。
The reality is that AI is like having a very eager junior developer on your team. They can write code quickly, but they need constant supervision and correction. The more you know, the better you can guide them.
这就造成了我所谓的知识悖论:资深工程师和开发人员使用人工智能来加速他们已经知道如何做的事情,而初级工程师则试图使用它来学习该做什么,结果却大相径庭。
This creates what I call the knowledge paradox: senior engineers and developers use AI to accelerate what they already know how to do, while juniors try to use it to learn what to do, and the results differ dramatically.
我曾亲眼目睹资深工程师们利用人工智能来:
I’ve watched senior engineers use AI to:
快速构建他们已经理解的想法原型
Rapidly prototype ideas they already understand
生成基本实现,然后他们可以对其进行细化
Generate basic implementations they can then refine
探索解决已知问题的替代方法
Explore alternative approaches to known problems
自动化日常编码任务
Automate routine coding tasks
与此同时,低年级学生经常:
Meanwhile, juniors often:
接受不正确或过时的解决方案
Accept incorrect or outdated solutions
忽略关键的安全性和性能因素
Miss critical security and performance considerations
调试人工智能生成的代码很困难
Struggle to debug AI-generated code
构建他们并不完全理解的脆弱系统
Build fragile systems they don’t fully understand
第三,本书旨在帮助工程经理和首席技术官应对人工智能对其团队和流程的影响。您将深入了解如何在人工智能时代构建团队、评估人才并保持代码质量,因为在这个时代,一名工程师就能完成过去需要团队协作才能完成的工作。本书提供的策略将帮助您顺利完成转型,同时保持工程文化的完整性。
Third, this book addresses engineering managers and CTOs grappling with the implications of AI on their teams and processes. You’ll gain insights into how to structure teams, evaluate talent, and maintain code quality in an era where a single engineer can produce what once required a team. The strategies here will help you navigate the transition while keeping your engineering culture intact.
本书并非编程入门指南。虽然人工智能让编程变得更加容易,但要有效运用它仍然需要经验积累带来的判断力。不妨将本书视为高级培训,面向那些准备超越传统编程、拥抱全新软件创建范式的人士。
What you won’t find here is a beginner’s guide to programming. While AI makes coding more accessible, wielding it effectively still requires judgment that comes from experience. Think of this book as advanced training for those ready to transcend traditional programming and embrace a new paradigm of software creation.
本书探讨了开发者的角色如何从实际敲击键盘的编程工作演变为产品工程。这意味着运用人类的判断力来指导人工智能,确保质量、架构和用户需求得到满足。我们依然需要创造力、系统思维和同理心,才能将一个功能完善的程序打造成一款优秀的产品。人工智能不会取代我们,而是会增强我们的能力——前提是我们能够明智地运用它。
This book explores how the role of developers is evolving, from hands-on-keyboard programming to product engineering. This means using human judgment to guide AI, ensuring that quality, architecture, and user needs are met. We still provide the creativity, system thinking, and empathy that turn a functional program into a great product. AI doesn’t replace us; it amplifies us—if we wield it wisely.
在第一部分,我将探讨“灵感编码”的优势领域:快速启动新产品、构建功能原型、编写标准CRUD应用或集成代码——在这些领域,速度和模式匹配比深度原创性更为重要。反之,我也会探讨我们在哪些方面仍需谨慎对待人工智能:例如,在真正复杂、底层或新颖的算法中,人工智能可能会遇到困难。认识到人工智能的现有局限性可以避免挫败感和失败;仍然有很多事情只有人类的智慧才能完成。
In Part I, I’ll identify domains where vibe coding excels: spinning up new products, prototyping features, churning out standard CRUD apps or integration code—all areas where speed and pattern matching trump deep originality. Conversely, I’ll also look at where we remain cautious about relying on AI: for truly complex, low-level, or novel algorithms where it might stumble. Recognizing the current limits of AI prevents frustration and failure; there’s still plenty only human ingenuity can achieve.
人的因素仍然是关键所在。我们确保架构的稳健性,调试棘手的漏洞,并超越“能运行”的层面来评判代码质量。至关重要的是,我们将以用户为中心的理念融入开发过程中——这是人工智能无法做到的。我们有责任确保软件不仅能够运行,而且能够以有意义的方式服务于用户。简而言之,开发人员成为人工智能输出的策展人和编辑,始终使其与现实世界的需求和高标准保持一致。
The human element remains the linchpin. We ensure the architecture is sound, debug the tricky bugs, and judge the quality of code beyond “it runs.” Critically, we infuse development with user-centric thinking—something an AI can’t do. It’s up to us to make sure the software not only works but works for the users in a meaningful way. In short, developers become curators and editors of AI output, always aligning it with real-world needs and high standards.
第二部分着眼于Vibe编码的实践层面。接受新的工作流程至关重要。“滚动而非修复”之类的技巧提醒我们不要陷入僵局——有时重新生成代码比调试更快。并行提示让我们能够同时从多个角度解决问题。我们必须在快速迭代和最终完善之间取得平衡,确保不会积累难以维护的混乱代码。模块化AI代码、全面的测试和迭代完善等最佳实践有助于在快速开发的同时保持代码库的整洁和健壮。
Part II looks at the practical aspects of vibe coding. Embracing new workflows is crucial. Techniques like “roll, not fix” remind us not to get bogged down—sometimes regenerating code is faster than debugging it. Parallel prompting lets us solve problems from multiple angles at once. We must balance rapid iteration with eventual refinement, ensuring we don’t accumulate unsustainable mess. Best practices like modularizing AI code, thorough testing, and iterative refinement help keep the codebase clean and robust despite the speed of development.
随着项目规模的扩大,我们必须应对代码量的快速增长和潜在的技术债务。人工智能可能会让你的代码库被大量代码淹没;只有严谨的纪律和良好的工程实践(或许再加上人工智能辅助的重构)才能保证代码的可维护性。在人员方面,我们将招聘并培训工程师,使他们能够熟练使用人工智能工具,并重视他们的适应能力和系统设计技能。同时,我们也知道何时应该回归传统模式——例如,在为产品长期维护而进行优化,或者在处理关键系统时,谨慎比速度更重要。
As projects scale, we have to manage an accelerated influx of code and potential technical debt. AI can flood your repo with code; only discipline and good engineering practices (plus maybe AI-assisted refactoring) will keep it maintainable. On the people side, we’ll hire and train engineers to be adept at using AI tools, valuing adaptability and system design skills. And we’ll know when to dial back into traditional modes—like when solidifying a product for long-term maintenance or handling critical systems where caution trumps velocity.
第三部分 涵盖安全性和可靠性、伦理道德,以及一系列让如今的“氛围式编码”成为可能的工具:例如 Cursor 和 Windsurf 等人工智能增强型集成开发环境 (IDE),它们集成了来自 Anthropic、Google Gemini 和 OpenAI 的模型,能够理解你的整个代码库并在各个环节提供帮助。了解应该应用哪些工具和模型(例如,针对不同任务使用 Claude 的变体,以及用于一般问答的 ChatGPT)是新一代开发者必备的技能之一。它们各有优势:Cursor 适合交互式编辑,Windsurf 适合处理上下文相关的任务,聊天界面适合头脑风暴和故障排除等等。
Part III covers security and reliability, ethics, and an arsenal of tools that make vibe coding possible today: AI-augmented IDEs like Cursor and Windsurf that integrate models from Anthropic, Google’s Gemini, and OpenAI to understand your entire codebase and assist at every turn. Knowing which tools and models to apply (Claude’s variants for different tasks, ChatGPT for general Q&A) is part of the new developer skill set. They each have strengths: Cursor for interactive editing, Windsurf for context-heavy tasks, chat interfaces for brainstorming and troubleshooting, etc.
展望未来,我预见到软件构建方式将更加抽象(例如通过图形用户界面和更高级别的输入进行“氛围设计”),随着人工智能生成更多定制化代码,对通用库的依赖性将降低,甚至会出现基于人工智能反馈循环自主演化的软件。在未来,软件的成功将高度依赖于人类的创造力、分发技巧以及驾驭网络效应的能力,因为编码的门槛将大大降低。人工智能的普及可能会催生新的用户体验范式——从对话式界面到自适应用户界面,乃至更广阔的领域。
Looking to the future, I anticipate even more abstract ways of building software (“vibe designing” through GUIs and higher-level input), diminishing reliance on generic libraries as AI generates more bespoke code, and even software that evolves on its own based on AI feedback loops. In this future, success in software will lean heavily on human creativity, distribution savvy, and the ability to harness network effects, because the brute-force barrier of coding will be so low. New user experience paradigms may emerge, driven by AI’s ubiquity—from conversational interfaces to adaptive UIs and beyond.
在这一切之中,有一个主题尤为突出:人类与人工智能优势的融合。任何一方单独存在都不如两者结合强大。人工智能带来速度、广博的知识和不知疲倦的执行力。人类则带来方向、深刻的理解和价值观。未来最佳的工作流程是一种共生关系——可以将其想象成一位技艺精湛的工匠与一位能力超群的学徒搭档,后者可以瞬间找到任何工具或参考资料。工匠的专业知识对于创造真正卓越的作品仍然至关重要。
In all of this, one theme stands out: the fusion of human and AI strengths. Neither alone is as powerful as both together. AI brings speed, breadth of knowledge, and tireless execution. Humans bring direction, depth of understanding, and values. The optimal workflow of the future is a symbiosis—think of it as pairing a master craftsperson with a superpowered apprentice who can instantly fetch any tool or reference. The craftsperson’s expertise is still crucial to create something truly excellent.
对于正在阅读本文的开发者们:是时候拥抱这些工具和范式了。本书将鼓励你在下一个项目中尝试使用人工智能编码助手,练习将问题分解,让人工智能来解决其中的一部分,并培养编写提示和筛选结果的技能。但本书也会敦促你更加专注于自身独特的价值所在——系统设计能力、用户共情能力以及使软件与现实相符的判断力。
For developers reading this: it’s time to embrace these tools and paradigms. This book will encourage you to experiment with an AI coding assistant on your next project, practice breaking problems down for an AI to solve parts of it, and cultivate that skill of crafting prompts and curating results. But it will also urge you to double down on what makes you uniquely valuable—your ability to design systems, empathize with users, and make judgment calls that align software with reality.
本书采用以下排版规范:
The following typographical conventions are used in this book:
指示新的术语、网址、电子邮件地址、文件名和文件扩展名。
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant widthConstant width用于程序清单,以及在段落中引用程序元素,例如变量或函数名称、数据库、数据类型、环境变量、语句和关键字。
Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
此元素表示一般性说明。
This element signifies a general note.
此元素表示警告或注意事项。
This element indicates a warning or caution.
40多年来,O'Reilly Media一直致力于提供技术和商业培训、知识和见解,以帮助企业取得成功。
For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.
我们独特的专家和创新者网络通过书籍、文章和我们的在线学习平台分享他们的知识和专业技能。O'Reilly 的在线学习平台让您可以按需访问直播培训课程、深入学习路径、交互式编程环境,以及来自 O'Reilly 和 200 多家其他出版商的大量文本和视频资源。欲了解更多信息,请访问https://oreilly.com。
Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.
请将有关本书的意见和问题直接发送给出版社:
Please address comments and questions concerning this book to the publisher:
我们为这本书设立了一个网页,上面列出了勘误表和任何其他信息。您可以通过以下网址访问该网页:https://oreil.ly/BeyondVibeCoding。
We have a web page for this book, where we list errata and any additional information. You can access this page at https://oreil.ly/BeyondVibeCoding.
有关我们书籍和课程的新闻和信息,请访问https://oreilly.com。
For news and information about our books and courses, visit https://oreilly.com.
在领英上找到我们:https://linkedin.com/company/oreilly-media。
Find us on LinkedIn: https://linkedin.com/company/oreilly-media.
在 YouTube 上观看我们:https://youtube.com/oreillymedia。
Watch us on YouTube: https://youtube.com/oreillymedia.
人工智能正在重塑我们构建软件的方式,引入了从自由提示到结构化辅助等一系列全新的编码范式。想象一下,你只需描述你想要软件实现的功能——就像和队友交流一样——人工智能就能将这些想法转化为代码。这就是氛围编码的精髓,它是一种以提示为先导的探索性方法,你用自然语言描述你想要的东西,然后让大型语言模型(LLM)来填补空白。该术语是人工智能先驱 Andrej Karpathy 最近创造的,用来描述这种新的编程方式,在这种方式中,开发人员“完全沉浸于”人工智能辅助的“感觉”之中。
AI is reshaping how we build software, introducing new paradigms for coding that range from free-form prompting to structured assistance. Imagine writing software by simply describing what you want it to do—almost like talking to a teammate—while an AI translates those ideas into code. This is the essence of vibe coding, a prompt-first, exploratory approach where you describe what you want in natural language and let a large language model (LLM) fill in the blanks. The term was recently coined by AI pioneer Andrej Karpathy to describe this new way of programming, where developers “fully give in to the vibes” of AI assistance.
在这本书中,我将深入探讨“氛围编码”对专业开发人员的意义,以及它与我称之为“人工智能辅助工程”(一种更正式的增强型编码过程)的比较和补充。我将探讨在人工智能优先的时代,开发者的角色是如何演变的,哪些工具和工作流程可以最大限度地提高你的效率,以及如何应对让人工智能在你的代码库中自由发挥所面临的独特挑战。我还会分析“灵感编码”的优势和不足,以及如何在人工智能生成速度和人类监督的智慧之间取得平衡。最后,你应该能够清晰地了解如何在自己的编码实践中负责任且高效地运用“灵感”,从而不仅成为一名速度更快的程序员,更成为一名在人工智能时代更具创造力和影响力的软件产品工程师。
In this book, I’ll dive deeper into what vibe coding means for professional developers and how it compares with—and complements—what I call AI-assisted engineering, a more formal augmented coding process. I’ll explore how the developer’s role is evolving in this AI-first era, what tools and workflows can maximize your effectiveness, and how to address the unique challenges of letting an AI loose on your codebase. I’ll also look at where vibe coding shines, where it struggles, and how to balance the speed of AI generation with the wisdom of human oversight. By the end, you should have a clear picture of how to harness “the vibes” in your own coding practice—responsibly and effectively—to become not just a faster coder but a more creative and impactful software product engineer in the age of AI.
在本章中,我们将探讨开发人员的角色如何从为机器编写详细的指令转变为通过表达意图与人工智能协作(见图1-1)。我们将了解为什么节目制作中的这种“氛围转变”如此重要,它在高层是如何运作的,以及它带来了哪些机遇和挑战。
In this chapter, we explore how the role of the developer is transforming from writing detailed instructions for machines to collaborating with AI by expressing intent (see Figure 1-1). We’ll see why this “vibe shift” in programming is such a big deal, how it works at a high level, and what opportunities and challenges it brings.
在过去一年里,我观察到开发人员(尤其是中高级 Web 开发人员)在工作流程中接受人工智能的方式出现了有趣的差异。光谱的一端是“氛围编码”(vibe coding),另一端是我称之为“人工智能辅助工程”(AI-assisted engineering)的方法:这是一种严谨的方法,在明确的约束条件下,将人工智能融入软件开发的每个阶段,从设计到测试。两种方法都利用了强大的人工智能,但它们的目标、受众和预期却截然不同。本书将探讨这两种极端方法及其对现代Web开发的意义。
Over the past year, I’ve observed a fascinating split in how developers—especially intermediate and advanced web developers—embrace AI in their workflow. On one end of the spectrum lies vibe coding. On the other end is what I’ll call AI-assisted engineering: a disciplined method of weaving AI into each phase of software development, from design through testing, under clear constraints. Both approaches leverage powerful AI, but their goals, audiences, and expectations differ markedly. Throughout this book, I’ll explore these two extremes and what they mean for modern web development.
在 Vibe 编码中,您可以利用强大的 LLM 作为编码伙伴,让它们处理繁重的代码生成工作,以便您可以专注于更高层次的目标。正如《商业内幕》的一篇总结文章所说,Vibe 编码“意味着使用 AI 工具……来完成繁重的编码工作,从而快速构建软件”。正如英伟达 CEO 黄仁勋所说,得益于 AI,“最热门的新型编程语言”是英语,而不是 Java 或 Python。你无需手动输入每个函数和 bug 修复代码,而是用自然语言与 AI 交互——勾勒功能草图、查看建议,并根据 AI 的输出进行迭代。
In vibe coding, you leverage powerful LLMs as coding partners, letting them handle the heavy lifting of code generation so you can focus on higher-level goals. As one Business Insider summary puts it, vibe coding “means using AI tools...for the heavy lifting in coding to quickly build software.” As NVIDIA’s CEO Jensen Huang says, thanks to AI, “the hottest new programming language” is English, not Java or Python. Instead of manually typing out every function and bug fix, you interact with the AI in natural language—sketching out features, reviewing suggestions, and iterating based on the AI’s output.
这种方法标志着从传统编程到人工智能辅助开发的巨大转变。传统编码需要精心规划、语法精确,而且往往需要耗费大量精力进行调试。Vibe 编码则颠覆了这一模式:“这根本算不上编码——我只是看到一些东西,说一些东西,运行一些东西,复制粘贴一些东西,而且大部分都能正常运行,”Karpathy 在接受Business Insider采访时打趣道,并强调了人工智能如何能够以最小的人工干预将高级指令转化为可运行的代码。
This approach represents a dramatic shift from traditional programming to AI-assisted development. Conventional coding demands careful planning, syntax precision, and often painstaking debugging. Vibe coding flips that script: “It’s not really coding—I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works,” Karpathy quipped to Business Insider, highlighting how AI can turn high-level instructions into working code with minimal manual effort.
开发者们正从编写详细的计算机指令转向借助人工智能来协调最终结果。例如,Karpathy 描述了他如何通过不断接受人工智能的建议来构建一个 Web 应用:“我总是‘全部接受’,不再查看差异……遇到错误信息时,我直接复制粘贴……有时 LLM 无法修复 bug,所以我只能想办法绕过它,或者请求一些随机的修改,直到问题消失。” 代码的“增长”超过了他通常自己编写的规模,但通过迭代的提示和修复,项目很快就能完成。本质上,Vibe 编码将编码视为与 AI 结对程序员的互动对话,而不是独自苦苦钻研语法和堆栈跟踪。其目标是速度和探索——以最小的阻力获得可行的解决方案。
Developers move from writing detailed instructions for computers to orchestrating outcomes with the help of AI. As an example, Karpathy describes building a web app by continually accepting the AI’s suggestions: “I ‘Accept All’ always, I don’t read the diffs anymore.…When I get error messages, I just copy paste them in.…Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away.” The code “grows” beyond what he’d normally write himself, yet the project comes together quickly through iterative prompting and fixing. Essentially, vibe coding treats coding as an interactive conversation with your AI pair programmer rather than as a solo slog through syntax and stack traces. The goal is speed and exploration—to get a working solution with minimal friction.
多种趋势的融合促成了氛围编码的实现。首先,现代人工智能编码助手(例如OpenAI 的法典,ChatGPT,Anthropic 的Claude 等程序员在生成和纠错代码方面已经变得异常出色。在同一篇文章中,Karpathy 指出,这“之所以成为可能,是因为这些高级编程语言(LLM)……变得太强大了”——它们已经吸收了大量的 GitHub 代码,能够为许多任务生成合理的解决方案。
Several trends converged to make vibe coding possible. First, modern AI coding assistants (like OpenAI’s Codex, ChatGPT, Anthropic’s Claude, etc.) have become astonishingly good at generating and correcting code. In the same post, Karpathy notes this is “possible because the LLMs…are getting too good”—they have ingested vast swaths of GitHub code and can produce plausible solutions for many tasks.
其次,涌现出了许多新的开发者工具,可以将这些模型无缝集成到编码工作流程中(稍后会详细介绍这些工具)。最后,开发者社区的思维方式正在转变,他们开始信任人工智能的辅助功能,并承担越来越多的工作。这不再仅仅是功能强大的自动补全,而是将整个函数或文件交给人工智能处理。实际上,使用 Vibe 编码就像拥有源源不断的、充满热情的初级开发者,随时准备实现你的任何需求——只不过他们的工作速度堪比云计算。
Second, new developer tools have emerged to integrate these models seamlessly into the coding workflow (more on these tools in a moment). Finally, the developer community’s mindset is evolving to trust AI assistance for bigger and bigger chunks of work. It’s no longer just autocomplete on steroids; it’s handing over whole functions or files to the AI. In practical terms, vibe coding often feels like having an unlimited supply of eager junior developers to implement whatever you ask for—except they work at the speed of cloud computation.
氛围编码最引人注目的优势之一是:生产力提升。早期用户反馈,他们创建软件功能或原型的速度比以前快了十倍到一百倍。例如,Codeium Windsurf 的工程师 John Hoestje 思考道:“为什么只做效率 10 倍的工程师,而不是效率 100 倍的工程师呢?” 这表明,有了合适的 AI 驱动型 IDE,实现卓越的生产力是触手可及的。像Windsurf这样的人工智能增强型集成开发环境(IDE)工具,“可以显著加快开发速度,让您实现100倍的生产力提升。” 虽然100倍可能是一个极端情况,但即使是更保守的研究也发现了巨大的收益。
One of the most eye-popping promises of vibe coding is the productivity boost. Early adopters report being able to create software features or prototypes ten to a hundred times faster than before. For instance, Codeium Windsurf engineer John Hoestje muses, “Why be a 10x engineer when you could be a 100x engineer?” This suggests that, with the right AI-powered IDE, extraordinary productivity is within reach. Tools like Windsurf, an AI-enhanced IDE, “can dramatically accelerate development time, allowing you to achieve that 100x productivity.” While 100x might be an extreme scenario, even more conservative studies find huge gains.
开发者可以在几秒钟内生成样板代码,瞬间修复 bug,甚至让 AI 编写测试或文档,将过去需要几天才能完成的工作流程压缩到短短几个小时。不再受限于打字速度或记忆力,一位拥有 AI 的开发者通常可以在一个周末内完成全栈应用程序的原型设计——这在过去可能需要一个小团队花费数周时间才能完成。这并非炒作;正如我在 2025 年 1 月为Pragmatic Engineer撰写的博文中提到的,调查显示,75% 的开发者已经将某种形式的 AI 集成到他们的工作流程中,许多公司报告称开发速度提高了两位数甚至三位数。简而言之,AI 结对程序员正在将传说中的“10 倍工程师”变成一个非常现实(且触手可及)的“100 倍工程师”现象。
Developers can generate boilerplate code in seconds, fix bugs in the blink of an eye, and even have AI write tests or docs, compressing workflows that used to take days into mere hours. No longer limited by typing speed or memory, a single developer armed with AI can often prototype a full stack application in a weekend—something that might have taken a small team weeks to accomplish in the past. It’s not just hype either; as I noted in a January 2025 blog post for Pragmatic Engineer, surveys show that 75% of developers have already integrated some form of AI into their workflows, and many companies report double- or triple-digit percentage improvements in development velocity. In short, AI pair programmers are turning the mythical “10x engineer” into a very real (and reachable) 100x engineer phenomenon.
为了理解这项技术的革命性意义,不妨考虑一个具体的例子。一位开发者想要构建一个简单的网页应用,用于统计播客脚本中的字数并估算阅读时间。他没有从零开始,而是打开一个人工智能驱动的编码环境,告诉人工智能他的想法。几分钟之内,人工智能就生成了一个可运行的原型。开发者接着说:“把统计计数器改成亮色,并添加导出PDF的功能”,人工智能便会相应地更新代码。最终,一个功能齐全的工具诞生了,只需点击一下即可部署——所有这一切都在不到10分钟的时间内完成。这个真实案例(由一位使用Replit人工智能的开发者分享)展示了“氛围编码”如何实现由高级需求驱动的极速迭代开发。同样,非工程师也开始参与其中:同一篇文章描述了一位没有任何编程背景的失业营销人员,他利用人工智能编码助手构建了100个简单的网页工具,这些工具最终都登上了Product Hunt的榜首。当软件开发的门槛如此之低时,我们不仅提高了经验丰富的开发者的效率,更重要的是,我们从根本上扩大了能够开发软件的人群。
To understand how revolutionary this is, consider a concrete example. A developer wants to build a simple web app that counts words in a podcast script and estimates reading time. Instead of starting from scratch, they open an AI-powered coding environment and tell the AI their idea. Within minutes, the AI produces a working prototype. The developer then says, “Make the stats counters bright colors and add a PDF export,” and the AI updates the code accordingly. The result is a functional tool, deployed with one click—all achieved in under 10 minutes. This real-world scenario (reported by a creator using Replit’s AI) shows how vibe coding enables extremely rapid, iterative development driven by high-level requests. Similarly, nonengineers are jumping in: the same article describes one laid-off marketer with no coding background who used an AI coding assistant to build 100 simple web tools that collectively reached the top of Product Hunt. When the barrier to creating software drops this low, we’re not just increasing productivity for seasoned developers—we’re fundamentally expanding who can develop software in the first place.
然而,直觉式编码也存在严重的弊端。由于过度依赖人工智能,最终生成的代码在理想情况下“运行正常”,但实际上却隐藏着大量漏洞或糟糕的设计决策。如果没有完善的计划或约束,低级逻辑模型(LLM)生成的解决方案可能缺乏适当的错误处理、安全检查或可扩展性。事实上,人工智能生成的代码有时就像建立在沙子上的建筑:它看起来坚固,但隐藏着只有在实际环境中才会显现的问题。我见过这样的案例:开发人员凭借直觉在极短时间内完成了一个功能,但后来却发现代码效率低下且难以维护。这种“纸牌屋”式的代码在压力下很容易崩溃。
However, vibe coding comes with serious caveats. Because you’re deferring so much to the AI, you might end up with code that “works” in the happy path but hides a minefield of bugs or poor design decisions. Without a solid plan or constraints, an LLM might generate a solution that lacks proper error handling, security checks, or scalability. In fact, AI-generated code can sometimes be built on sand: it appears solid but has hidden issues that only surface under real-world conditions. I’ve seen cases where a developer vibed their way to a complete feature in record time, only to discover later that the code was inefficient and hard to maintain. This kind of “house of cards” code can collapse under pressure.
例如,想象一下让人工智能“快速搭建一个用户登录系统”。人工智能或许能迅速生成一个可用的身份验证流程,但它可能使用了简化的加密方法或已知存在漏洞的库。如果你在没有进行深入检查的情况下就部署它,那就等于盲目相信一切都万无一失。经验丰富的工程师都知道这样做风险很大:生产环境中运行的代码必须易于理解且值得信赖。正如一位专家所说:“用即兴创作的方式编写生产代码库显然是危险的。我们软件工程师的大部分工作都涉及对现有系统进行改进,而底层代码的质量和可理解性至关重要。” 而即兴创作的方式,在极端情况下,可能会绕过这些质量关卡。
For example, imagine asking an AI to “whip up a user login system.” The AI might produce a working authentication flow quickly, but perhaps it uses a simplified encryption method or a known vulnerable library. If you deploy that without deeper inspection, you’re taking on faith that everything is sound. Seasoned engineers know that’s risky: code running in production has to be understood and trusted. As one expert put it, “Vibe coding your way to a production codebase is clearly risky. Most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.” Vibe coding, at its extreme, can bypass those quality gates.
另一个挑战是,Vibe 编码往往会忽略前期规划。传统的软件工程重视清晰性和约束性设计——通过数据模型进行思考,选择合适的模式,并编写至少一份最基本的规范。Vibe 编码方式则反其道而行之:它不提供任何脚手架,而是通过提示直接进入实现阶段。这可能会导致开发过程漫无目的。你可能会因为不断提示而陷入困境——例如,AI 选择了一种你意料之外的状态管理方法或库,现在你不得不要么引导它回到原点,要么接受现状。如果没有初始蓝图,最终的架构可能会显得杂乱无章。这对于快速的概念验证来说尚可接受,但在需要保持一致性的大型代码库中却会造成诸多问题。
Another challenge is that vibe coding tends to downplay upfront planning. Traditional software engineering values designing for clarity and constraint-thinking through data models, choosing appropriate patterns, and writing out at least a minimal spec. Vibe coding flips this: it starts with no scaffolding, diving straight into implementation via prompts. That can lead to a meandering development process. You might prompt your way into a corner—say the AI chooses a state management approach or library you didn’t intend, and now you have to either steer it back or live with it. Without an initial blueprint, the final architecture might be haphazard. This is fine for a quick proof of concept, but it’s troublesome in a larger codebase where consistency matters.
氛围型编程本身并非“坏事”。事实上,它的出现是编程民主化进程的一部分。它降低了软件开发的门槛,就像早期的低代码平台或脚本语言一样。一个积极主动、思路清晰的非工程师,仅凭直觉就能构建一个简单的应用程序。对于经验丰富的开发者来说,直觉编码可以成为强大的头脑风暴工具——它类似于伪代码,但能立即生成可运行的结果。关键在于认识到它的局限性。速度若缺乏严谨性,会导致软件脆弱不堪,因此直觉编码需要有人全程参与并保持警惕。我经常提醒开发者(也提醒我自己):“直觉编码不是低质量工作的借口。”它应该是解决方案的起点,而不是终点。
Vibe coding isn’t inherently “bad.” In fact, its emergence is part of the ongoing democratization of programming. It lowers the barrier to creating software, much like early low-code platforms or scripting languages did. A motivated nonengineer with a clear idea could potentially build a simple app through vibes alone. And for experienced developers, vibe coding can be a powerful brainstorming tool—it’s like pseudo coding but with immediate, runnable results. The key is recognizing its limits. Speed without discipline can lead to brittle software, so vibe coding requires a vigilant human in the loop. I often remind developers (and myself) that “vibe coding is not an excuse for low-quality work.” It should be the start of a solution, not the end.
与此相反的是人工智能辅助工程——一种更有条理、更有条理的软件构建方式,人工智能在每一步都扮演着辅助驾驶员的角色。在这里,开发商仍然掌握着绝对的主导权。AI 辅助工程包括在传统的软件开发生命周期 (SDLC) 中使用 AI,例如 AI 驱动的自动完成、聊天、代码迁移、错误检测、测试生成以及细粒度(功能、模块、组件)和完整代码生成(见图1-2)。
On the opposite end of our spectrum is AI-assisted engineering—a more structured, methodical way of building software with AI as a copilot at every step. Here, the developer remains very much in the driver’s seat. AI-assisted engineering includes using AI across the traditional software development lifecycle (SDLC), such as AI-powered autocomplete, chat, code migrations, bug detection, test generation, and both granular (function, module, component) and full code generation (see Figure 1-2).
首先,你需要制定一个计划(即使只是一个简单的计划),概述你需要构建的内容,并预先定义约束条件和验收标准。然后,有针对性地引入人工智能工具,以加速或增强计划中的某些部分。与以灵感为先的“直觉式”编码不同,我们可以将这种以人工智能为支撑的“计划优先”开发模式称为“计划优先”开发。这可以像迷你产品需求文档(针对某个功能的简短产品需求文档)那样正式,也可以像任务清单那样简单。关键区别在于,在让AI自由发挥之前,你需要明确工作的目标和限制条件。
You begin with a plan (even if it’s lightweight), outlining what you need to build and defining the constraints and acceptance criteria up front. Then you incorporate AI tools in a targeted manner to accelerate or enhance parts of that plan. In contrast to prompt-first vibe coding, we might call this “plan-first” development with AI support. This could be as formal as a mini-product requirements document (a short PRD for a feature) or as simple as a checklist of tasks. The crucial difference is that you ground the work in clear intent and constraints before letting the AI loose.
假设一位 React 开发人员的任务是创建一个新的交互式仪表盘组件。在人工智能辅助的工程方法中,他们可能会首先编写组件的职责和 API:
Consider a React developer tasked with creating a new interactive dashboard component. In an AI-assisted engineering approach, they might begin by writing down the component’s responsibilities and API:
仪表盘组件显示分析卡片列表,支持按日期范围筛选,并包含刷新和导出按钮。它应从我们的 API 获取数据(并具备适当的错误处理机制),且必须遵循我们的样式设计规范。
Dashboard component shows a list of analytics cards, supports filtering by date range, and has refresh and export buttons. It should fetch data from our API (with proper error handling), and it must follow our design system for styling.
这份概要本质上就是一份规范。开发者甚至可以快速绘制一个数据模型草图,或者确定哪些现有的实用函数可以复用。只有到了这一步,他们才会引入人工智能:例如,使用支持人工智能的集成开发环境(IDE)或代码助手,根据这份描述生成组件的框架。人工智能可能会提供一个 React 组件的初始实现,其中包含用于数据获取的占位符和模拟事件处理程序。由于开发者提供了清晰的指导,人工智能的输出更有可能符合项目的需求(例如使用正确的设计系统类或调用正确的 API 端点)。代码并非出乎意料,而是源于一个结构清晰的需求。
This outline is essentially a spec. The developer might even sketch a quick data model or identify existing utility functions to reuse. Only then do they bring in the AI: for instance, using an AI-enabled IDE or coding assistant to generate the skeleton of the component based on that description. The AI might provide a starting implementation of the React component with placeholders for data fetching and stubbed event handlers. Because the developer provided clear guidance, the AI’s output is more likely to align with the project’s needs (such as using the right design system classes or calling the correct API endpoints). The code isn’t a surprise; it’s the product of a well-formed request.
人工智能辅助工程并不仅仅局限于为单个组件生成代码。它以可控的方式贯穿整个开发生命周期。对于日常编码任务,像 GitHub Copilot 这样的 AI 自动补全工具可以在你输入时建议接下来的几行代码,从而在你实现已知模式时节省击键次数。例如,当你编写单元测试时,你的 AI 助手可以根据函数名称自动建议断言。说到测试,你可以在功能实现后使用 AI 生成测试用例——将组件的规范或代码输入提示框,即可获得你应该检查的边界情况建议。其理念是增强工程师的工作,而不是取代它。你仍然需要思考逻辑并验证正确性;AI 只是帮你分担了一些繁琐的工作。
AI-assisted engineering doesn’t stop at code generation for a single component. It permeates the entire development lifecycle in a controlled fashion. For routine coding tasks, an AI autocompletion tool like GitHub Copilot can suggest the next few lines as you type, saving keystrokes when you’re implementing known patterns. For example, as you write a unit test, your AI helper might autosuggest assertions based on the function name. Speaking of tests, you might use AI to generate test cases once a feature is in place—feeding the component’s spec or code into a prompt to get suggestions for edge cases you should check. The idea is to augment the engineer’s work, not replace it. You’re still thinking through the logic and verifying correctness; the AI just offloads some of the grunt work.
在代码迁移或重构方面,人工智能可以成为一大助力。想象一下,你需要将一个基于类的 React 组件转换为一个带有 Hooks 的现代函数组件。与其手动完成所有操作,不如让 AI 助手来转换代码,或者至少概述转换步骤。凭借对新旧模式的深刻理解,LLM(生命周期管理)可以生成重构后的代码草稿,然后由你进行审查和润色。这种结构化的 AI 使用方式,能够逐一处理定义明确的任务(例如“将这段代码从 Redux 迁移到 React Context API”),而不是赋予 AI 一个开放式的“构建任何内容”的任务。
When it comes to code migration or refactoring, AI can be a godsend. Imagine needing to convert a class-based React component to a modern function component with hooks. Rather than doing it all manually, you could ask an AI assistant to transform the code or at least outline the steps. With a good understanding of the old and new patterns, an LLM can produce a draft of the refactored code, which you then review and polish. This structured use of AI tackles well-defined tasks (like “migrate this code from Redux to React Context API”) one by one rather than handing the AI an open-ended “build whatever” mandate.
人工智能辅助工程最引人注目的形式或许是利用人工智能根据详细规范生成完整的微型应用程序或功能。现在有很多工具允许你输入应用程序的描述(类似于迷你版产品需求文档),然后就能得到一个可运行的代码库或原型。例如,开发者可以提供以下方面的规范:
Perhaps the most dramatic form of AI-assisted engineering is using AI to generate a full mini-application or feature from a detailed specification. Several tools now allow you to input a description of an app, something akin to a mini-PRD, and get back a working codebase or prototype. For instance, a developer could supply a spec for:
一个使用 React 前端和 Node.js 后端开发的待办事项应用,支持用户身份验证和实时更新。
a to-do list app with React frontend and Node.js backend, supporting user authentication and real-time updates
人工智能工具将搭建项目框架,创建关键组件,并设置数据库架构。
The AI tool would scaffold the project, create the key components, and set up the database schema.
这并非魔法;它只是勤勉的工程师在启动新项目时可能采取的步骤(例如设置目录、选择库、编写样板代码)的加速版。关键在于,人工智能的创造力受到规范中给出的约束。最终生成的是一个符合您提供的需求的最小可行产品 (MVP)。经验丰富的开发人员如果正确对待这个输出,不会认为第一代产品就已可以投入生产。相反,他们会将其视为初稿。他们会运行应用程序,编写或重新生成测试来验证每个功能,检查代码是否存在任何不一致或不安全的配置,并根据需要进行改进。简而言之,他们会运用所有常规的工程严谨性——只是借助人工智能根据蓝图批量生成代码的能力而加快了速度。
This isn’t magic; it’s an accelerated version of what a diligent engineer might do when starting a new project (setting up directories, choosing libraries, writing boilerplate code). The important thing is that the AI’s creativity is bounded by the constraints given in the spec. The result is a minimum viable product (MVP) that adheres to the requirements you provide. An experienced developer, treating this output correctly, will not assume it’s production-ready on the first generation. Instead, they’ll treat it as a first draft. They’ll run the app, write or regenerate tests to validate each feature, review the code for any inconsistencies or insecure configurations, and refine as needed. In short, they’ll apply all their usual engineering rigor—just accelerated by an AI’s ability to produce bulk code from a blueprint.
人工智能辅助工程的目标与氛围编码的目标不同。这里的目标不仅是快速编写出可运行的代码,更是要更高效地编写出高质量的代码。这关乎在提高生产力的同时,保持(甚至提升)结果的可靠性。一个实践人工智能辅助工程的团队可能会说:“我们希望以两倍的速度交付这项功能,但绝不降低我们的标准。”
The goals of AI-assisted engineering are different from those of vibe coding. The aim here is not just to get working code quickly but to get high-quality code more efficiently. It’s about boosting productivity while preserving (or even improving) the reliability of the outcome. A team practicing AI-assisted engineering might say, “We want to deliver this feature two times faster but with zero compromise on our standards.”
这种方法的目标受众通常是拥有成熟流程(代码审查、测试、部署流程)且不愿放弃这些流程的专业开发人员和团队。这些中高级工程师将人工智能视为工具箱中强大的新工具,而不是工具箱的替代品。他们很可能已经目睹过偷工减料的后果,因此他们重视那些能够保持软件可维护性的实践。(相比之下,Vibe Codeing 的目标受众包括独立开发人员(他们自己搭建演示程序)、具有一定编码知识的产品经理,甚至还包括利用人工智能来弥补自身技能不足的相对较新的程序员。)
The audience for this approach is typically professional developers and teams who have established processes (code review, testing, deployment pipelines) that they aren’t willing to abandon. These are intermediate to senior engineers who see AI as a powerful new tool in their toolbox, not a replacement for the toolbox. They likely have seen what happens when you cut corners, so they value practices that keep software maintainable. (By way of comparison, the audience for vibe coding includes solo developers hacking together demos, product-minded folks with some coding knowledge, and even relatively new programmers who leverage AI to compensate for gaps in their expertise.)
人工智能辅助工程的预期是,人类仍然掌控决策,而人工智能提供建议或加速器。代码质量、性能和安全性至关重要,因此,每一段由人工智能生成的代码都必须接受与初级开发人员编写的代码相同的严格审查。要把人工智能视为你的实习生,而不是你的替代品。你可以将任务委派给它,但你必须审查它的工作。正如你绝不会在未经代码审查的情况下部署人类实习生编写的代码一样,你也不应该在不理解人工智能代码的情况下就部署它。这种理念始终将工程纪律置于首位。
The expectations in AI-assisted engineering are that humans remain in control of decisions, and the AI provides suggestions or accelerators. Code quality, performance, and security remain paramount, so every AI-generated piece is subject to the same scrutiny as if a junior developer wrote it. Treat the AI as your intern, not your replacement. You might delegate tasks to it, but you must review its work. Just as you’d never deploy code written by a human intern without a code review, you shouldn’t deploy AI-written code without understanding it. This mindset keeps the engineering discipline front and center.
Vibe编码和AI辅助工程是两种截然不同的思维模式。Vibe 编码是自上而下、探索式的:你从一个宽泛的想法开始,然后通过与 AI 的交互逐步实现。这有点像即兴爵士乐——结构极简,为创意即兴发挥留出大量空间,你在演奏的过程中逐渐发现歌曲的雏形。而 AI 辅助工程则是系统化、迭代式的:更像是古典作曲,你从一个主题或动机(你的需求)开始,有条不紊地发展它,或许会在乐谱的节拍内运用一些即兴发挥(AI 的建议)。两者都能产生“音乐”,但过程和结果类型会有所不同。
Vibe coding and AI-assisted engineering are two distinct mindsets. Vibe coding is top-down and exploratory: you start with a broad idea and let the implementation emerge through interaction with the AI. It’s a bit like improvisational jazz—minimal structure, lots of room for creative riffs, and you discover the shape of the song as you play. AI-assisted engineering is systematic and iterative: more like classical composition, where you begin with a theme or motif (your requirements) and methodically develop it, perhaps using some improvisation (AI suggestions) within the measures of a written score. Both can produce “music,” but the process and the kind of result will differ.
对于中级或高级 Web 开发人员来说,对每种方法的预期至关重要。如果你采用的是 Vibe 编码,那么你肯定会感到惊喜。人工智能可能会提出你意想不到的方案——也许它会使用你不太熟悉的库或编程惯用法。它的魅力之一就在于从这些惊喜中学习,或者快速克服那些你觉得繁琐的部分。但你也需要预料到可能会出现一些小问题。Vibe 编码的爱好者应该做好心理准备,他们最终还是要负责解决最后那棘手的问题。它的神奇之处确实存在,但并非完美无缺。
For an intermediate or advanced web developer, your expectations for each approach are key. If you’re vibe coding, you expect to be surprised. The AI might come up with an approach you wouldn’t have written yourself—maybe it uses a different library or a programming idiom you’re less familiar with. Part of the allure is learning from those surprises or quickly getting past things you find tedious. But you also need to expect hiccups. Vibe-coding enthusiasts should go in with eyes open that they’ll be responsible for that tricky last stretch. The magic is real, but it’s not total.
如果你正在实践人工智能辅助工程,你的期望值应该如何设定?对于长期项目而言,这种方式更加审慎,也更贴近实际。你期望人工智能能够节省时间,或许还能启发一两个解决方案,但并非要它包揽你所有的工作。事实上,优秀的AI辅助工程师可能会在更大的框架内,以微剂量的方式运用类似“灵感提示”的方式。例如,在实现一个定义明确的模块时,他们可能会短暂地切换到“灵感提示模式”,询问:“嘿,AI,快速生成一个格式化这些日期的实用函数”,然后立即切换回工程师模式,集成并检查该函数。这种理念的核心在于,AI是你的合作者,在你的指导下工作。你将它擅长的任务(例如样板代码、重复性代码、大范围实现)分配给它,而其余部分(关键逻辑、集成、最终审核)则由你亲自处理。
If you’re practicing AI-assisted engineering, your expectations are more measured and arguably more realistic for long-term projects. You expect the AI to save you time and perhaps inspire a solution or two but not to do your whole job. In fact, a good AI-assisted engineer might use vibe-style prompting in microdoses within a larger framework. For example, while implementing a well-specified module, they might momentarily switch into “vibe mode” to ask, “Hey AI, generate a quick utility function to format these dates,” then immediately switch back to engineer mode to integrate and check that function. The mindset is that AI is a collaborator that works under your guidance. You allocate tasks to it where it excels (like boilerplate, repetitive code, broad-stroke implementations), and you handle the rest yourself (critical logic, integration, final review).
预期目标包括提高生产力、减少重复性错误(例如,人工智能不太可能拼错变量名),以及可能拓宽解决方案的搜索范围(人工智能可能会提出你未曾想到的算法)。但你也需要投入时间进行验证。 调试 AI 辅助代码仍然是调试:你需要运行测试,并在需要时使用调试器单步执行代码。不同之处在于,你可能会发现自己需要调试 AI 为你编写的代码,这是一种全新的体验,需要一定的学习过程。第五章将详细讨论这种体验。
Expectations here include improved productivity, fewer rote mistakes (an AI is less likely to misspell a variable name, for instance), and possibly a broader solution search space (the AI might suggest an algorithm you hadn’t thought of). But you also expect to invest time in validation. Debugging AI-assisted code is still debugging: you run tests and step through the code in the debugger if needed. The difference is that you might find yourself debugging code the AI wrote for you, which is a new experience that comes with a learning curve. Chapter 5 will discuss this experience in detail.
这两种方法目标凸显了二者之间的根本区别:以“氛围编码”为导向的编程注重短期内的速度,而人工智能辅助工程则注重持续的速度和可靠性。一位“氛围编码”程序员可能会说:“我需要在今晚之前让这个应用运行起来,看看这个想法是否可行。”而一位人工智能辅助工程师则会说:“我需要快速构建这个功能,但它必须足够健壮,能够在我们的代码库中长期存在。”前者只要代码基本能运行就满足了;后者则更关心代码是否足够简洁,以便其他人可以在此基础上进行开发。
The two approaches’ goals highlight a fundamental difference between them: vibe coding optimizes for velocity in the short term, whereas AI-assisted engineering optimizes for sustained velocity and reliability. A vibe coder might say, “I need to get this app running by tonight to see if the idea works.” An AI-assisted engineer would say, “I need to build this feature fast, but it should be robust enough to live in our codebase for years.” The former is satisfied if the code basically functions; the latter cares that the code is clean enough for others to build upon.
这些差异自然会吸引不同的受众。经验不足的开发者或非工程领域的从业者可能更倾向于使用“灵感编码”(vibe coding),因为它降低了入门门槛,并能带来即时的成就感。我曾遇到过一些产品经理和设计师,他们通过灵感提示尝试编写代码,几乎把人工智能当作一个功能强大的 Stack Overflow,能够提供完整的解决方案。另一方面,经验丰富的开发者和工程团队则更倾向于使用人工智能辅助工程。他们之前曾被脆弱的代码坑过,所以他们一开始就秉持着“即使使用新工具来加快速度,也要把事情做好”的原则。他们愿意在前期投入更多精力(例如编写小型产品需求文档、搭建项目结构),以换取长期的回报。
These differences naturally appeal to different audiences. Less-experienced developers or those outside the engineering discipline might lean toward vibe coding because it lowers the barrier to entry and provides instant gratification. I’ve met product managers and designers dabbling in code via vibe prompts, treating the AI almost like a superpowered Stack Overflow that gives them full solutions. On the flip side, seasoned developers and engineering teams tend to favor AI-assisted engineering. They’ve been burned by fragile code before, so they start from a place of “let’s do this right, even if we use new tools to go faster.” They put in a bit more effort up front (writing that mini-PRD, setting up the project structure) in exchange for long-term payoffs.
人们不禁要问:哪种方法更好?事实上,灵感编码和人工智能辅助工程并非互斥的概念:它们代表着同一光谱的两端,而实际工作流程往往融合了两者的元素。开发者可能会先用灵感编码搭建一个新颖的框架,然后再切换到工程模式进行完善。或者,他们通常遵循人工智能辅助的开发方法,但偶尔——比如对于一个无关紧要的一次性脚本或一个临时原型——也会说:“不如试试灵感编码,看看效果如何。”关键在于理解其中的利弊,并在合适的场景下采用合适的方法。
It’s tempting to ask: which approach is better? The truth is, vibe coding and AI-assisted engineering aren’t mutually exclusive categories: they represent two ends of a spectrum, and real-world workflows often blend elements of both. A developer might start a project with a burst of vibe coding to scaffold something novel, then switch into engineering mode to firm it up. Or they might generally follow an AI-assisted discipline but occasionally—for a trivial one-off script or a throwaway prototype—say, “You know what, I’ll just vibe code this and see what I get.” The key is understanding the trade-offs and using the right approach for the right context.
把灵感编码想象成一辆高速探索车:它能带你快速偏离常规路线,非常适合探索发现。而人工智能辅助工程则更像是一列行驶在轨道上的可靠列车:虽然需要事先铺设轨道(规划),但它更安全可靠,更有可能顺利抵达目的地而不脱轨。中高级开发者应该能够驾驭这两种方式,但他们会根据手头的任务进行选择。如果目标是快速创新或构思(例如,在黑客马拉松中或验证想法的可行性时),灵感编码可以提供动力。但请记住,如果计划重用代码,一定要进行优化。如果目标是在专业环境中构建可维护的产品功能,那么采用人工智能辅助工程可以确保你的代码库中不会出现一段无人真正理解的“黑盒”代码。
Think of vibe coding as a high-speed exploratory vehicle: it can take you off the beaten path quickly, and it’s great for discovery. AI-assisted engineering is more like a reliable train on a track: you have to lay down rails first (plan), but it’s a safer bet and more likely to reach a defined destination without derailing. Intermediate and advanced developers should be capable of driving both vehicles, but they’ll choose based on the task at hand. If the goal is to innovate or ideate rapidly (say, in a hackathon or when validating an idea’s feasibility), vibe coding provides momentum. Just remember to tighten things up if you plan to reuse that code. If the goal is to build a maintainable product feature in a professional setting, leaning toward AI-assisted engineering ensures you don’t end up with a black-box chunk of code in your codebase that nobody truly understands.
我观察到一个很有意思的现象:随着开发者使用人工智能工具的经验积累,他们的使用方式往往会自然而然地从追求新奇体验转向工程应用。最初,人工智能能够根据一个指令生成整段代码,这种新奇感非常吸引人——谁不想尝试一下“用语言”创造一个应用程序呢?
One fascinating thing I’ve observed is that as developers gain experience with AI tools, their usage often naturally shifts from the vibe end toward the engineering end. Initially, the novelty of having an AI generate entire blocks of code from a single prompt is alluring—who wouldn’t want to try essentially “talking” an app into existence?
但蜜月期过后,务实的态度开始显现。开发者们开始意识到人工智能的优势和不足。他们学会将问题分解,分阶段地交给人工智能处理,而不是一次性要求它给出完整的解决方案。实际上,他们从“提示艺术家”转变为人工智能的“指挥家”——仍然利用人工智能的创造力,但同时以娴熟的技巧引导它,并遵循清晰的乐谱。在我的实践中,我更加注重提示,通常会编写一小段伪代码或注释,然后让AI完成它们,而不是直接提出开放式问题。这样,我既能获得类似直觉式的流畅性,又能保持在可控的结构之内。
But after the honeymoon, pragmatism kicks in. Developers start to see where the AI shines and where it stumbles. They learn to break problems down and feed them to the AI in pieces rather than asking for the whole solution in one go. In effect, they move from being “prompt artists” to becoming AI “orchestra conductors”—still utilizing the AI’s creative power but guiding it with a skilled hand and following a clear score. In my own practice, I’ve become more deliberate with prompts, often writing small pieces of pseudocode or comments and asking the AI to complete them instead of just asking open-ended questions. This way, I get the benefits of vibe-like fluidity but within a structure I control.
值得注意的是,工具也在不断发展,以支持整个范围。一方面,我们有专门为氛围编码设计的基于聊天的界面和自然语言编码环境,在这些环境中,你甚至可能要等到自己提出要求才能看到代码。另一方面,集成开发环境(IDE)正在添加人工智能功能。它们可以无缝融入传统编码:例如,AI 代码检查器可以提出改进建议,文档生成器可以解释代码,版本控制机器人可以自动创建拉取请求并建议更改以供审查。 这些工具鼓励工程思维,它们融入到通常的开发工作流程(编辑、审查、测试等)中,同时还能利用人工智能。
It’s also worth noting that tooling is evolving to support the entire spectrum. On one side, we have chat-based interfaces and natural-language coding environments explicitly designed for vibe coding, where you might not even see the code until you ask for it. On the other, IDEs are adding AI features that seamlessly blend into traditional coding: for example, AI linters that suggest improvements, documentation generators that explain code, and version-control bots that can automatically create a pull request and suggest changes for review. These tools encourage an engineering mindset by fitting into the usual development workflow (edit, review, test, etc.) while still leveraging AI.
随着最佳实践的出现,直觉式编码和人工智能辅助工程之间的界限或许会逐渐模糊。我们可能会发现,如今看似“随性而为”的做法会受到更多约束,而看似“结构化工程”的做法则会变得更加灵活。事实上,我认为理想的未来是我们可以在两者之间轻松切换:需要时,我们可以利用人工智能探索创新解决方案;而当需要强化和发布软件时,我们则始终运用扎实的工程实践来约束一切。
The distinction between vibe coding and AI-assisted engineering might even blur over time as best practices emerge. We may find that what today feels like “vibing” will gain more guardrails, and what feels like “structured engineering” will become more fluid. In fact, I’d argue that the ideal future is one where we can move up and down this spectrum effortlessly: exploring creative solutions with AI when we want to but always reining things in with solid engineering practices when it’s time to harden and ship the software.
这些方法的多样性代表了我们如今使用人工智能工具方式的重大变革。然而,即便我们不断改进与人工智能协作的技术——无论是通过快速的灵感编码还是结构化的工程工作流程——一场更为根本的变革正在悄然发生。编程本身的本质正在改变。我们正在摆脱开发者必须将想法转化为明确指令的传统模式,走向一个我们可以直接表达意图,并让人工智能负责将其转化为代码的未来。
This spectrum of approaches represents a significant evolution in how we work with AI tools today. Yet even as we refine our techniques for collaborating with AI—whether through rapid vibe coding or structured engineering workflows—a more fundamental transformation is taking shape. The very nature of programming itself is changing. We’re moving away from the traditional paradigm where developers must translate their ideas into explicit instructions and toward a future where we can express our intentions directly and let AI handle the translation into code.
这种转变挑战了我们对程序员身份最基本的认知。几代以来,我们的价值都与我们像机器一样思考的能力紧密相连——将问题分解成计算机可以执行的离散逻辑步骤。但是,当机器不仅能够理解我们告诉它们要做什么,还能理解我们想要什么时,又会发生什么呢?这就是“意图编程”的由来,它不仅代表了一种新的工具或技术,更是对开发者角色的一次根本性重新定义。
This shift challenges our most basic assumptions about what it means to be a programmer. For generations, our value has been tied to our ability to think like machines—to break down problems into discrete, logical steps that computers can execute. But what happens when machines become capable of understanding what we want, not just what we tell them to do? This is where programming with intent enters the picture, representing not just a new tool or technique but a fundamental reimagining of the developer’s role.
几十年来,编程一直意味着编写指令:一行又一行的代码告诉计算机如何做某事。每个函数、循环和条件语句都必须由人精心编写。而意图编程则颠覆了这一模式。开发者不再关注底层实现,而是专注于结果或目标:你希望程序完成什么。你用高层次的方式(通常是自然语言)表达你的意图,人工智能系统就会自动生成实现该意图的代码。
For decades, programming has meant writing instructions: line after line of code telling the computer how to do something. Each function, loop, and conditional had to be carefully crafted by a human. Programming with intent flips this script. Instead of focusing on the low-level implementation, the developer focuses on the outcome or goal: what you want the program to accomplish. You express that intent in a high-level way (often in natural language), and the AI system figures out the code to fulfill it.
不妨这样理解:传统编程就像是给别人一步一步地指路,而基于意图的编程则像是告诉他们目的地,让他们自己去寻找最佳路线。通过关注“做什么”而不是“怎么做”,开发者可以在更高的抽象层次上工作。这种方法并非全新——可视化编程、低代码平台和代码生成器等工具早已承诺提升抽象层次。但如今人工智能的进步终于使得用简单的语言描述复杂行为并生成可运行的代码成为可能。
Think of it this way: traditional coding is like giving someone step-by-step directions, while intent-based coding is like telling them your destination and letting them figure out the best route. By focusing on the what instead of the how, developers can work at a higher level of abstraction. This approach isn’t entirely new—tools like visual programming, low-code platforms, and code generators have long promised to raise the abstraction level. But today’s AI advancements are finally making it practical to describe complex behaviors in plain language and get working code in return.
这种转变的核心在于看似不起眼的提示。提示是你提供给人工智能编码系统的输入或问题。本质上,它是对你希望程序做什么的描述,而不是如何执行的指令。这与编写代码的感觉截然不同。例如,你可能不会编写循环来解析文件,而是会提示:
At the heart of this shift is the humble prompt. A prompt is the input or question you give to an AI coding system. In essence, it’s a description of what you want the program to do rather than an instruction for how to do it. This can feel very different from writing code. For example, instead of writing a loop to parse a file, you might prompt:
读取此 CSV 文件并提取所有 18 岁以上用户的电子邮件地址。
Read this CSV file and extract the email addresses of all users older than 18.
人工智能将尝试生成能够实现该描述的代码。
The AI will attempt to generate code that accomplishes that description.
为什么现在会发生这种情况?语言学习模型(LLM)在理解和生成文本(包括编程语言)方面的快速发展改变了游戏规则。这些人工智能模型已经过海量代码和自然语言文本的训练。它们能够解读看似软件行为描述的提示,并将其转化为实现该行为的实际代码。换句话说,它们已经学习了人类描述任务的方式以及这些任务如何转化为代码的模式。
Why is this happening now? The rapid progress of LLMs in understanding and generating text, including programming languages, has been a game changer. These AI models have been trained on vast amounts of code and natural language text. They can interpret a prompt that looks like a description of software behavior and translate it into actual code that implements that behavior. In other words, they’ve learned the patterns of how humans describe tasks and how those tasks translate into code.
这种基于提示的开发的兴起意味着,作为开发者,你越来越多地使用自然语言或伪代码来描述功能和逻辑,而让AI来处理编写语法正确代码的繁重工作。提示成为了你新的思考单位,是对意图的简洁表达。我们已经从告诉计算机“先做X,再做Y,最后做Z”转变为说“我需要完成X、Y和Z”,然后信任AI会填补空白。
This rise of prompt-based development means that, as a developer, you increasingly write descriptions of features and logic in natural language or pseudocode and let the AI handle the heavy lifting of writing syntactically correct code. The prompt becomes your new unit of thought. It’s a concise expression of intent. We’ve gone from telling the computer, “Do X, then Y, then Z” to saying, “I need X, Y, and Z done” and trusting the AI to fill in the blanks.
值得注意的是,编写好的提示本身就是一项技能(我们将在第三章深入探讨)。模糊的提示会导致代码错误或效率低下,就像模糊的需求会让程序员感到困惑一样。你在提示中表达的意图越清晰,人工智能的输出就越能满足你的需求。这就是为什么许多人将编写提示称为新的编程素养。
It’s important to note that writing a good prompt is itself a skill (which we’ll dive into in Chapter 3). A vague prompt can lead to incorrect or inefficient code, just as a vague requirement can confuse a human programmer. The better you can articulate your intent in the prompt, the better the AI’s output will match your needs. This is why many are calling prompt writing the new programming literacy.
那么人工智能是如何从如何将你的自由描述转化为实际可运行的代码?关键在于大型语言模型(LLM)能够解读上下文并生成文本。 “大型”中的“大型”指的是其参数(内部配置)的数量,通常高达数十亿甚至更多,这使得它能够捕捉自然语言和编程语言的复杂性。这些模型基于公共代码库、论坛、文档和问答网站进行训练,学习编程语言的语法以及代码解决问题的语义。当你与人工智能程序员互动时,你实际上是在利用这些庞大的学习知识。让我们用简单易懂的方式来解释一下:
So how does an AI go from your free-form description to actual, functioning code? The magic lies in LLMs’ ability to interpret context and generate text. The large in “large language model” refers to the number of parameters (the internal configuration) it has, often billions or more, which enable it to capture the complexities of natural and programming languages. These models have been trained on public code repositories, forums, documentation, and Q&A sites, learning both the syntax of programming languages and the semantics of how code is used to solve problems. When you interact with an AI coder, you’re tapping into this expansive learned knowledge. Let’s break it down in simple terms:
什么时候你提供一个提示(例如,“生成一个函数来检查一个数是否为质数”),AI 模型会分析该提示文本。来自 Google、OpenAI 和 Anthropic 的现代模型已经过无数语言和代码示例的训练,因此它们会利用统计模式来推断你的问题。本质上,AI 会尝试预测最有可能用合理的代码完成提示。
When you provide a prompt (for example, “Generate a function that checks if a number is prime”), the AI model analyzes the text of that prompt. Modern models from Google, OpenAI, and Anthropic have been trained on countless examples of language and code, so they use statistical patterns to infer what you’re asking. Essentially, the AI tries to predict the most likely completion of the prompt with code that makes sense.
这些人工智能系统通常会考虑除单行提示之外的其他上下文信息。例如,如果您在集成开发环境 (IDE) 中使用 AI 助手,该模型可能会考虑当前文件内容、您的编码风格、注释,甚至相关文件。所有这些上下文信息都有助于 AI 生成适合您项目的代码。这与人类开发人员阅读周围代码和文档以了解下一步操作的方式类似。
These AI systems often take into account additional context beyond just the single-line prompt. For instance, if you’re working in an IDE with an AI assistant, the model might also consider the current file content, your coding style, comments, and even related files. All this context helps the AI generate code that fits your project. It’s similar to how a human developer reads surrounding code and documentation to understand what to do next.
一旦模型理解了你的意图(或者至少做出了最佳猜测),它就会开始生成代码。在底层,它会逐个处理词元(词元是单词或代码符号的一部分),并利用训练过程中学习到的概率进行处理。这个模型并不像传统意义上的模型那样“思考”;它没有编译器或运行时来检查代码。它只是非常擅长以高概率生成正确代码的方式继续文本,因为它之前已经见过大量的示例。如果提示和上下文清晰,它生成的代码可以非常准确,甚至遵循它在训练数据中看到的最佳实践。
Once the model has understood (or at least made a best guess about) your intent, it proceeds to generate code. Under the hood, it does this one token at a time (a token is a piece of a word or code symbol) using probabilities learned during its training. The model doesn’t “think” in the conventional sense; it doesn’t have a compiler or runtime checking the code. It’s simply very good at continuing text in a way that has a high chance of being correct code because it has seen so many examples before. If the prompt and context are clear, the code it produces can be remarkably accurate and even follow best practices it has seen in its training data.
重要的是,人工智能不会擅自运行并为你部署应用程序。您始终参与其中。您可以审核生成的代码,进行测试,并决定接受或修改。在许多情况下,如果您提出要求,AI 还可以提供代码解释,帮助您理解结果。AI 的角色就像一个助手,为您编写代码——但您,作为开发者,仍然是最终的决策者,负责确保代码的正确性并满足项目需求。
Importantly, the AI doesn’t run off and deploy your application for you. You remain in the loop. You review the generated code, test it, and can accept or modify it. In many cases, the AI might also offer an explanation of the code if asked, helping you understand the result. The AI’s role is like an assistant that drafts the code for you—but you, the developer, are still the decision maker who ensures the code is correct and fits the project’s needs.
真正令人印象深刻的是,整个过程只需几秒钟甚至更短的时间即可完成。简而言之,你的描述(提示)会被输入到预测引擎(LLM)中,引擎会生成可能的代码作为输出。虽然模型的内部运作涉及复杂的数学和神经网络层,但对用户而言,这几乎就像是在与一位专家合作,这位专家几乎可以立即回忆起如何实现任何功能。
What’s truly impressive is that this process happens in seconds or less. The high-level overview is that your description (prompt) goes into a prediction engine (the LLM), which produces likely code as output. While the inner workings of models involve complex math and neural network layers, at the user level, it feels almost like collaborating with an expert who can instantly recall how to implement just about anything.
中的一个理解“直觉式编程”(基于意图的编程)的关键在于,它是一个人与人工智能之间迭代协作的过程。你不能只写一个完美的提示,然后就坐等人工智能完美地编写出整个程序。实际上,你需要与人工智能进行反复的交流,形成一个反馈循环,逐步将模糊的想法转化为完善的代码。
One of the key things to understand about vibe coding (intent-based programming) is that it’s an iterative, collaborative process between the human and the AI. You don’t just write one perfect prompt and then sit back as the AI writes an entire program flawlessly. In practice, you engage in a back-and-forth, a feedback loop that gradually takes a vague idea to polished code.
Here’s how a typical cycle might look:
这是您的初始提示或请求。例如:
This is your initial prompt or request. For example:
生成一个函数,根据本金、利率和期限计算每月贷款还款额。
Generate a function to calculate monthly loan payments given principal, interest rate, and term.
人工智能会为该函数生成代码,包括参数和贷款支付公式。它甚至可能还会添加解释公式的注释。
The AI generates code for that function, complete with parameters and formula for loan payments. It might even include comments explaining the formula.
你查看代码。它逻辑清晰吗?它能处理特殊情况吗?你快速测试一下:如果利率为 0 会怎样?它运行正常吗?你发现它可能无法很好地处理这种情况。
You look at the code. Does it make sense? Does it handle edge cases? You run a quick test: what if the interest rate is 0? Does it behave correctly? You notice it might not handle that scenario well.
如果代码不够完美(通常第一次尝试都不会完美),请进行改进。您可以再次提示 AI(“修改函数以优雅地处理 0% 的利率”),或者自己编辑代码并告诉 AI “解释一下这部分”,如果有什么不清楚的地方。这些指导有助于纠正任何误解。
If the code isn’t perfect (and often it won’t be on the first try), refine it. Maybe you prompt the AI again (“Modify the function to handle a 0% interest rate gracefully”), or edit the code yourself and tell the AI, “Explain this part,” if something is unclear. This guidance helps correct any misunderstandings.
人工智能会接收您的反馈或新的提示并调整代码。现在,该函数会检查是否存在零利率情况并进行相应的处理。
The AI takes your feedback or new prompt and adjusts the code. Now the function checks for zero interest and handles it appropriately.
你重复这个循环,直到满意为止。接下来,你或许会要求 AI 为这个函数生成单元测试,以确保它能正常工作。AI 生成测试后,你运行这些测试来验证一切正常。
You continue this loop until satisfied. Perhaps next you ask the AI to also generate unit tests for this function to ensure it works correctly. It does so, and you run them to verify all is well.
这种协作模式很像结对编程,其中一人是人类,另一人是人工智能助手。人类设定方向并了解高层需求,而人工智能则提供建议、编写样板代码并加快繁琐部分的执行速度。对于复杂的任务,两者单独都难以有效完成:人工智能需要人类提供指导和验证,而人类也会将部分工作交给人工智能以加快进度。
This collaboration is much like a pair-programming scenario where one partner is the human and the other is an AI assistant. The human sets the direction and knows the high-level requirements, while the AI offers suggestions, writes boilerplate, and speeds up the tedious parts. Neither is effective alone for complex tasks: the AI relies on the human for direction and validation, and the human offloads some work to the AI to move faster.
至关重要的是,迭代不仅仅是修正错误,更是不断完善解决方案。你可以先给出一个非常粗略的提示,然后根据人工智能的运行结果逐步改进你的意图。
Crucially, the iteration isn’t just about fixing errors; it’s also about evolving the solution. You might start with a very rough prompt and then progressively refine your intent as you see what the AI produces.
这有助于培养实验精神。如果第一次尝试如果答案不正确,你也没浪费太多时间——只需改进提示或调整代码,然后重试即可。在传统编程中,编写一个模块后又不得不丢弃,这会令人沮丧;但对于人工智能生成的代码而言,即使犯错,成本也很低,这鼓励我们探索不同的方法。
This encourages a mindset of experimentation. If the first attempt isn’t right, you haven’t wasted much time—just refine the prompt or tweak the code and try again. In traditional coding, writing a module only to throw it away can be frustrating, but with AI-generated code, the cost of a false start is low, encouraging exploration of different approaches.
为什么是有目的地进行编程真的那么重要吗?这种转变具有几个深远的影响:
Why is programming with intent such a big deal? This shift has several profound implications:
或许最直接的好处就是速度。当人工智能处理重复性工作时,开发人员可以更快地完成任务。一些原本可能需要数小时手动编写的常规代码(例如设置数据库模型、API 端点或数据清理脚本)现在通常只需几分钟即可生成。早期关于人工智能编码助手的研究也证实了这一点:使用 GitHub Copilot 等工具的开发人员完成任务的速度显著提升(一项研究发现,在 Copilot 的辅助下,特定任务的耗时缩短了 55%)。如果将这些优势应用到整个项目中,就预示着未来软件开发周期将大幅缩短,团队迭代速度也将显著提升。
Perhaps the most immediate benefit is speed. Developers can accomplish tasks faster when the AI handles the rote work. Routine code that might take hours to write by hand (like setting up database models, API endpoints, or data cleaning scripts) can often be generated in minutes. Early studies on AI coding assistants back this up: developers using tools like GitHub Copilot have been shown to complete tasks significantly faster (one study found a 55% time reduction on a given task with Copilot assistance). When you multiply these gains across an entire project, it hints at a future where software development cycles shorten dramatically and teams can iterate more quickly.
除了速度上的提升,还有心理上的好处。编写样板代码或查找语法会打断程序员的思路和思路。有了人工智能处理这些干扰,开发者就能专注于他们正在解决的问题。许多用户表示,在人工智能的帮助下,他们不再为繁琐的任务而感到沮丧,能够专注于编码的创造性和设计方面。换句话说,人工智能通过分担枯燥的部分,让编码变得更加轻松愉快,进而提升工作质量(快乐的程序员往往能写出更好的代码)。
Beyond raw speed, there’s a psychological benefit. Writing boilerplate or looking up syntax can break a programmer’s flow and train of thought. With an AI handling many of those interruptions, developers can stay focused on the problem they’re solving. Many users report that with AI help, they feel less frustrated by tedious tasks and can concentrate on the creative and design aspects of coding. In other words, it can make coding more enjoyable by offloading the boring parts, which in turn can improve the quality of the work (a happier coder often produces better code).
传统编程需要学习严谨的代码语法以及各种库和框架的特性。而基于意图的编程则将部分负担转移到了人工智能身上。新手可能记不住打开文件的确切语法或绘图函数的参数,但如果他们能描述自己的需求,人工智能就能自动补全这些细节。这并不意味着任何人都能在零知识的情况下编写复杂的系统(你仍然需要理解程序应该做什么),但这确实意味着更快地获得有用的结果。可以想象,领域专家(例如生物学家或经济学家)即使不是专业开发人员,也可以通过描述自身需求来编写各自领域的原型。从这个意义上讲,对于那些有想法和意图但缺乏深厚编程技能的人来说,编程变得更加容易上手。
Programming has traditionally required learning the exacting grammar of code and the quirks of various libraries and frameworks. With intent-based programming, some of that burden shifts to the AI. A newcomer might not remember the exact syntax to open a file or the parameters of a graphing function, but if they can describe what they want, the AI can fill in those details. This doesn’t mean anyone can code complex systems with zero knowledge (you still need to understand what the program should do), but it does mean that the ramp-up to producing useful results is shorter. It’s conceivable that domain experts (like a biologist or an economist) could write prototypes in their field by describing their needs, even if they’re not professional developers. In this sense, programming becomes more accessible to people who have the ideas and intent but not deep coding skills.
随着人工智能承担越来越多的代码生成任务,人类开发者的角色也在不断演变。架构设计、问题分解和验证等技能变得愈发重要。你可能会发现,自己花费在决定构建什么以及审查代码运行(或失效)原因上的时间,比编写语法代码的时间还要多。“懂得如何编写代码”的本质可能会转变为“懂得如何让人工智能编写代码”。这或许能够使软件开发的某些方面更加普及,同时也能提升专业人士的工作水平。我们很可能会看到围绕如何有效引导人工智能而涌现出的新最佳实践(我将在第三章介绍这一主题,并在本书后续章节中反复提及)。
As AI takes on more code generation, the role of the human developer evolves. Skills like architectural design, problem decomposition, and validation become even more important. You might find yourself spending more time deciding what to build and reviewing why the code works (or doesn’t) than typing out the syntax. The nature of “knowing how to code” may shift toward “knowing how to get the AI to code.” This could democratize certain aspects of software development while also elevating the level at which professionals operate. We’ll likely see new best practices centered around how to effectively guide AI (a topic I’ll introduce in Chapter 3 and revisit throughout the book).
有趣的是,随着人工智能处理更多常规编码工作,人类开发者可以将精力集中在更高层次的创造性任务上,例如优化用户体验、集思广益地构思新功能,或者解决人工智能自身难以妥善解决的棘手算法问题。在这种理想情况下,人工智能可以提高重复性编码工作的效率(占80%),从而解放你的精力,让你专注于更具创造性的20%。这改变了我们分配精力的方式。
Interestingly, as AI handles more routine coding, human developers can focus on higher-level creative tasks like refining the user experience, brainstorming new features, or tackling tricky algorithmic problems that AI might not solve well on its own. In this ideal scenario, the AI increases productivity on the repetitive 80% of coding, freeing your mental energy for the inventive 20%. It’s a shift in how we allocate our effort.
然而,事情并非总是尽如人意。这种新的开发模式也带来了一些挑战:
However, it’s not all rainbows and sunshine. This new style of development also raises challenges:
人工智能编写的代码值得信任吗?如果不逐行检查,就可能存在错误被忽略的风险。开发者需要对人工智能生成的代码进行彻底的测试和审查。确保输出结果正确、安全且高效是人的责任。盲目信任人工智能的输出结果存在风险,我们将在下文中讨论这一点。
Can you trust the code an AI writes? If you don’t see every line, there’s a risk of mistakes going unnoticed. Developers need to thoroughly test and review AI-generated code. The onus is on the human to ensure the output is correct, secure, and efficient. Blindly trusting AI output is risky, as we’ll discuss.
如果依赖人工智能进行日常编码,你会不会逐渐丧失从零开始编写代码或深入调试问题的能力?这类似于过度依赖计算器会削弱算术能力。开发者需要有意识地在便利性和保持对基础知识的扎实理解之间找到平衡。
If you rely on AI for routine coding, will you gradually lose your ability to write that code from scratch or debug issues deep in the weeds? It’s a concern akin to overreliance on calculators weakening arithmetic skills. Developers will need to consciously balance convenience with maintaining a solid understanding of the fundamentals.
随着目标导向型编程的普及,行业可能会重视不同的技能。未来对只会编写样板逻辑的人才需求可能会降低,而对能够设计系统、集成组件和验证正确性的人才需求则会增加。软件工作的性质可能会发生转变,人工智能将承担更多的实现工作,而人类则专注于设计和监督。
As programming with intent becomes widespread, the industry might value different skills. There may be less demand for people who are good at just cranking out boilerplate logic, and more demand for those who can design systems, integrate components, and verify correctness. The nature of software jobs could shift, with AI handling more implementation and humans focusing on design and oversight.
此外,最关键的因素之一是“氛围编码”的考量因素之一是上下文窗口的大小。Gemini 拥有所有 AI 模型中最长的上下文窗口,这在处理大型项目时可能具有颠覆性的意义。现在,一些模型支持超过一百万个令牌的上下文窗口,使其能够感知整个应用程序。开发者可以将整个代码库输入到人工智能系统中,以获得全面的理解。
Additionally, one of the most critical factors in “vibe coding” is context window size. Gemini offers the longest context window of all AI models, which can be game changing when working with large projects. Some models now support context windows of over a million tokens, allowing them to maintain awareness of entire applications. Developers can feed entire codebases to an AI for comprehensive understanding.
我们将在本章末尾更深入地探讨这些权衡取舍。但首先,让我们熟悉一下实现这种新型编码方式的新兴工具。
We’ll delve into these trade-offs more at the end of the chapter. But first, let’s familiarize ourselves with the emerging tools that enable this new way of coding.
Vibe 编码可能是一种理念,但它是由新一代人工智能工具实现的。经验丰富的开发人员如果想要采用这种工作流程,就需要熟悉一些关键平台和模型,这些平台和模型能够有效地实现人工智能辅助编码。
Vibe coding may be a philosophy, but it’s enabled by a new generation of AI-powered tools. Experienced developers who want to embrace this workflow will need to get acquainted with some key platforms and models that make AI-assisted coding effective.
本节将快速介绍Vibe Code工具包中的必备工具。这些工具包括Visual Studio Code (VSCode)及其不断增长的AI功能和扩展生态系统、新一代AI集成IDE(如Cursor和Windsurf)、LLM(如Claude及其各种版本)以及ChatGPT。本节不涉及后台编码代理,但我将在第10章中详细讨论它们。
This section is a quick tour of the essential tools in the vibe coder’s toolkit. These include Visual Studio Code (VSCode) with its growing ecosystem of AI features and extensions, next-gen AI-integrated IDEs like Cursor and Windsurf, LLMs like Claude (in its various versions), and ChatGPT. This section does not cover background coding agents, but I discuss them in detail in Chapter 10.
阅读本节时,不必费心记忆具体的工具名称或功能;这个领域发展迅速。我们的目标是了解可用的解决方案类型。
As you read this section, don’t worry about memorizing specific tool names or features; the landscape is evolving fast. The goal is to understand the types of solutions available.
通过与 GitHub Copilot 的深度集成, VSCode已从全球最受欢迎的代码编辑器转型为功能全面的 AI 辅助开发平台。这一演变体现了微软的愿景,即在数百万开发者日常使用的 VSCode 环境中保留 AI 功能。
VSCode has transformed from the world’s most popular code editor into a comprehensive AI-assisted development platform through its deep integration with GitHub Copilot. This evolution represents Microsoft’s vision for keeping AI capabilities within the familiar VSCode environment that millions of developers already use daily.
GitHub Copilot 是一款集成到 VSCode 中的 AI 代码助手。它能根据自然语言提示和现有代码上下文,提供代码建议、解释和自动实现。这款集成最突出的特点在于其无缝性——Copilot 不仅仅是一个插件,而是编辑器本身的自然延伸。
GitHub Copilot is an AI-powered coding assistant integrated into VSCode. It provides code suggestions, explanations, and automated implementations based on natural language prompts and existing code context. What sets this integration apart is its seamless nature—Copilot isn’t just an add-on but feels like a natural extension of the editor itself.
VSCode AI 功能的核心在于三种主要的交互模式。首先是内联代码自动补全,Copilot 会在您输入代码时提供内联代码建议,范围从单行代码补全到完整的函数实现。在您编写代码时,屏幕上会显示带有建议的提示文本,您可以按 Tab 键接受建议,也可以逐字部分接受。
The core of VSCode’s AI capabilities centers on three main modes of interaction. First, there’s inline code autocompletion, where Copilot provides inline code suggestions as you type, ranging from single-line completions to entire function implementations. As you write code, ghost text appears with suggestions that you can accept with Tab or partially accept word by word.
其次,还有一个聊天界面,可以通过侧边栏面板访问,您可以在这里讨论代码、提出问题或请求特定的实现。第三点,也许也是最强大的一点,是代理模式。它使用工具调用来访问 Visual Studio 中不断增长的功能集。给定一个目标,它会逐步选择并执行正确的工具。这种代理模式可以分析您的代码库,建议对多个文件进行修改,运行终端命令,响应构建错误,并在循环中进行自我纠正,直到任务完成。
Second, there’s the chat interface, accessible through a sidebar panel where you can have conversations about your code, ask questions, or request specific implementations. Third, and perhaps most powerful, is the agent mode that uses tool calling to access a growing set of capabilities inside Visual Studio. When given a goal, it selects and executes the right tools step-by-step. This agent mode can analyze your codebase, propose edits across multiple files, run terminal commands, respond to build errors, and self-correct in a loop until the task is completed.
VSCode 的 Copilot 实现之所以如此引人注目,是因为它支持模型上下文协议 (MCP)。MCP 为 AI 模型提供了一种标准化的方式,使其能够发现外部工具、应用程序和数据源并与之交互。这意味着 VSCode 中的 Copilot 可以连接到数据库、调用 API、访问文档,并与您的整个开发生态系统集成。例如,启用 GitHub MCP 服务器后,您可以让 Copilot “为我们讨论的每个 bug 创建一个 issue”,它将直接与 GitHub 的 API 交互来创建这些 issue。MCP 带来的可扩展性使 Copilot 从一个代码生成器转变为一个全面的开发助手,它不仅理解您的代码,还理解您的整个工作流程。
What makes VSCode’s Copilot implementation particularly compelling is its support for the Model Context Protocol (MCP). MCP provides a standardized way for AI models to discover and interact with external tools, applications, and data sources. This means Copilot in VSCode can connect to databases, invoke APIs, access documentation, and integrate with your entire development ecosystem. For instance, with the GitHub MCP server enabled, you can ask Copilot to “create an issue for each bug we discussed,” and it will interact directly with GitHub’s API to create those issues. The extensibility through MCP transforms Copilot from a code generator into a comprehensive development assistant that understands not just your code but your entire workflow.
要在专业开发中有效利用 VSCode 和 Copilot,首先要根据任务的复杂程度探索不同的交互模式。对于简单的代码补全和重构,可以依赖内联建议和错误附近出现的闪光图标——点击该图标即可获得 AI 驱动的修复。
To leverage VSCode with Copilot effectively in professional development, start by exploring the different interaction modes based on your task complexity. For simple code completions and refactoring, rely on the inline suggestions and the sparkle icon that appears near errors—click it for AI-powered fixes.
对于更复杂的任务,请打开聊天面板,然后从下拉菜单中选择“代理”来切换到代理模式。代理模式针对跨项目多个文件进行自主编辑进行了优化。它对于不仅需要编辑代码,还需要调用工具和终端命令的复杂任务尤其有用。VSCode 熟悉的界面与 Copilot 不断发展的 AI 功能相结合,为希望在现有开发环境中获得企业级 AI 辅助的团队提供了一个极具吸引力的选择。
For more complex tasks, switch to agent mode by opening the chat panel and selecting “Agent” from the drop-down. Agent mode is optimized for making autonomous edits across multiple files in your project. It is particularly useful for complex tasks that require not only code edits but also the invocation of tools and terminal commands. The combination of VSCode’s familiar interface with Copilot’s evolving AI capabilities offers a compelling option for teams that want enterprise-grade AI assistance without leaving their established development environment.
在探索专用的 AI IDE 之前,值得了解一下Cline(前身为 Claude Dev)如何将 VSCode 转变为强大的 AI 辅助开发环境。Cline 代表着与微软 Copilot 截然不同的理念。它并非紧密集成的助手,而是一个能够独立完成复杂、多步骤开发任务的自主编码代理。这款开源扩展为 VSCode 带来了超越专有 AI 编辑器的强大功能,同时又保持了 VSCode 用户所期望的灵活性和可扩展性。
Before exploring purpose-built AI IDEs, it’s worth examining how Cline (formerly Claude Dev) transforms VSCode into a powerful AI-assisted development environment. Cline represents a different philosophy from Microsoft’s Copilot. Rather than being a tightly integrated assistant, it functions as an autonomous coding agent that can take on complex, multistep development tasks from start to finish. This open source extension brings capabilities to VSCode that often exceed those found in proprietary AI editors, all while maintaining the flexibility and extensibility that VSCode users expect.
Cline 的独特之处在于其真正以用户为中心的软件开发方法。当你向 Cline 发出类似“创建一个……”这样的高级请求时,它会立即响应。“用于用户管理及身份验证的 REST API”并非简单地生成样板代码。相反,它会分析您的项目结构,规划跨多个文件的实现,创建正确的文件夹层次结构,安装必要的依赖项,甚至可以运行测试来验证实现。在整个过程中,Cline 始终保持透明,向您展示每个计划操作——文件创建、修改和终端命令——并让您有机会批准或修改每个步骤。这种人机协作的设计在自动化和控制之间实现了完美的平衡,使开发人员既能利用 AI 的功能,又能保持对代码库的掌控。
What distinguishes Cline is its truly agentic approach to software development. When you give Cline a high-level request like “Create a REST API for user management with authentication,” it doesn’t simply generate boilerplate code. Instead, it analyzes your project structure, plans the implementation across multiple files, creates proper folder hierarchies, installs necessary dependencies, and can even run tests to verify the implementation. Throughout this process, Cline maintains transparency by showing you each planned action—file creations, modifications, and terminal commands—and giving you the opportunity to approve or modify each step. This human-in-the-loop design provides the perfect balance between automation and control, allowing developers to leverage AI’s capabilities while maintaining oversight of their codebase.
Cline 的技术能力远不止代码生成。它可以利用浏览器自动化功能来研究 API 文档,通过分析多个文件中的错误跟踪来调试复杂问题,甚至可以通过其 MCP 支持与外部服务进行交互。在调试过程中,您只需粘贴错误消息,Cline 就会跟踪您的代码库以识别根本原因,提出修复方案,实施修复,并添加适当的错误处理以防止类似问题再次发生。其 MCP 集成意味着 Cline 可以连接到您的数据库以了解模式,然后再生成查询;可以访问您的项目管理工具以使实现与需求保持一致;还可以与任何其他兼容 MCP 的服务进行交互。这种可扩展性使 Cline 从一个代码生成器转变为一个能够理解您整个技术生态系统的全面开发合作伙伴。
Cline’s technical capabilities extend far beyond code generation. It can use browser automation to research API documentation, debug complex issues by analyzing error traces across multiple files, and even interact with external services through its MCP support. For debugging, you can paste an error message, and Cline will trace through your codebase to identify the root cause, propose a fix, implement it, and add appropriate error handling to prevent similar issues. Its MCP integration means Cline can connect to your database to understand schemas before generating queries, access your project management tools to align implementations with requirements, or interact with any other MCP-compatible service. This extensibility transforms Cline from a code generator into a comprehensive development partner that understands your entire technical ecosystem.
对于团队而言,Cline 提供了诸多极具吸引力的优势。作为开源软件,团队可以查看其代码、贡献改进或根据自身需求进行 fork——这对于有特定安全或合规性要求的组织至关重要。它支持多种 AI 提供商,包括 Anthropic 的 Claude、OpenAI 的模型、Google 的 Gemini,甚至可以通过 Ollama 支持本地模型,使团队能够根据性能、成本或数据驻留要求灵活选择模型。
For teams, Cline offers several compelling advantages. Being open source, teams can inspect its code, contribute improvements, or fork it for custom needs—crucial for organizations with specific security or compliance requirements. It supports multiple AI providers including Anthropic’s Claude, OpenAI’s models, Google’s Gemini, and even local models through Ollama, giving teams flexibility in model selection based on performance, cost, or data residency requirements.
要高效使用 Cline,请精心设计包含项目背景和约束条件的详细提示,充分利用其在进行任何更改前分析整个代码库的功能,并充分利用其迭代开发能力。Cline 实现某个功能后,您可以立即进行测试,并在同一对话中提出改进建议。VSCode 成熟的生态系统与 Cline 的自主开发功能相结合,为团队提供了一条强大、灵活且经济高效的 AI 辅助开发路径,而无需放弃现有的工具和工作流程。
To use Cline effectively, craft detailed prompts that include project context and constraints, leverage its ability to analyze your entire codebase before making changes, and take advantage of its iterative development capabilities. After Cline implements a feature, you can immediately test it and request refinements in the same conversation context. The combination of VSCode’s mature ecosystem with Cline’s autonomous capabilities offers teams a powerful, flexible, and cost-effective path to AI-assisted development without abandoning their existing tools and workflows.
vibe-coding 运动的旗舰工具之一是 Cursor,这是一款 AI 增强型 IDE,它迅速在寻求更流畅编码体验的开发人员中流行起来。Cursor 本质上是一个以人工智能为先导的代码编辑器(实际上是 VSCode 的一个分支),它将最先进的代码生成和理解功能直接构建到您的开发环境中。
One of the flagship tools of the vibe-coding movement is Cursor, an AI-enhanced IDE that has quickly gained popularity among developers seeking a more fluid coding experience. Cursor is essentially an AI-first code editor (a fork of VSCode, in fact) that builds state-of-the-art code generation and understanding right into your development environment.
它的标语是“AI 代码编辑器”,旨在让您使用纯文本指令编写和修改代码。例如,您可以高亮显示一个函数,然后让 Cursor “优化此函数”或“在此处添加错误处理”,它会立即给出代码更改建议。Cursor 的 AI 具有项目感知能力——它会索引您的代码库并理解文件的上下文,因此可以提供更相关的建议(远超简单的自动完成功能)。Cursor IDE 将 LLM 功能集成到其核心界面中。ChatGPT 了解你的代码库。
Its tagline is “The AI Code Editor,” and it’s designed to let you write and modify code using plain language instructions. For example, you can highlight a function and ask Cursor to “optimize this function” or “add error handling here,” and it will instantly suggest the code changes. Cursor’s AI is project-aware—it indexes your codebase and understands the context of your files, so it can make more relevant suggestions (far beyond a simple autocomplete). Cursor IDE integrates LLM capabilities into its core interface. It’s ChatGPT that knows your codebase.
在Cursor 利用高级语言模型(通常是 Anthropic 的 Claude 或 OpenAI 的模型,具体取决于您的设置)来增强其功能。它有一个聊天侧边栏,你可以在这里讨论代码,甚至还有一个“Composer”模式,用于生成多步骤代码。Andrej Karpathy 本人在他的“ vibe-coding”(氛围编码)实验中就使用了 Cursor 的 Composer 功能,并搭配了一个名为“Sonnet”的模型。这套设置让他能够直接与编辑器对话(通过“SuperWhisper”语音转文字功能),并生成代码,然后他可以接受或修改这些代码。
Under the hood, Cursor leverages advanced language models (often Anthropic’s Claude or OpenAI’s models, depending on your setup) to power its features. It has a chat sidebar where you can have conversations about your code, and even a “Composer” mode for multistep code generation. Andrej Karpathy himself has used Cursor’s Composer with a model called “Sonnet” in his vibe-coding experiments. This setup allowed him to literally talk to the editor (using voice-to-text via “SuperWhisper”) and have code appear, which he would then accept or refine.
游标不仅可以生成代码,而且根据指示,也需要编辑现有代码。例如,您可以询问:
Cursor can not only generate code but also edit existing code when instructed. For example, you can ask:
能否简化传输监听器中切换证书的操作?
Could you make it easier to switch certificates in the transport listener?
Cursor 会识别您指的是代码,并建议直接在相关文件中进行编辑,或从相关文件(例如规范 Markdown 文件)中读取内容(参见图 1-3)。免费版通常会在聊天窗口中显示差异供您确认;专业版则可以自动将更改应用到您的工作区。
Cursor will understand you’re referring to your code and propose direct edits in the relevant file or read from relevant files, such as a specification markdown file (see Figure 1-3). In the free version, it often provides the diff in the chat for you to approve; in the pro version, it can auto-apply changes to your workspace.
要在专业工作流程中有效使用 Cursor,您应该系统地利用其各项功能。首先在 Cursor 中打开聊天窗口,描述您想要的功能或修复。例如:添加一个包含邮箱和密码的用户登录表单,并设置验证和错误信息。Cursor 会生成所需的代码(创建新文件或修改现有文件),并以草稿形式呈现。您可以查看这些更改(它会显示差异或预览),然后点击“应用”将其合并到您的代码库中。许多开发者都遵循这个流程:提出建议 → 查看 → 接受。如果建议不够完善,您可以进一步完善您的建议(例如,“使用 Tailwind CSS 来设置表单样式”),或者直接让 Cursor 修复您发现的任何问题(“现在,处理邮箱已被注册的情况”)。本质上,您需要不断与您的代码“对话”,直到它看起来完美无缺。
To use Cursor effectively in a professional workflow, you should take advantage of its capabilities systematically. Start by opening a chat in Cursor and describe the feature or fix you want. For instance: add a user login form with email and password, including validation and error messages. Cursor will generate the needed code (creating new files or modifying existing ones) in a draft state. You can review these changes (it shows a diff or preview) and then hit “Apply” to merge them into your codebase. Many developers follow this loop: prompt → review → accept. If the suggestion isn’t perfect, you can refine your prompt (for instance, “Use Tailwind CSS for styling the form”) or just ask Cursor to fix any issues you spot (“Now, handle the case where the email is already registered”). In essence, you converse with your code until it looks good.
Cursor 在理解错误和日志方面也表现出色。如果您运行代码后得到回溯信息或错误消息,您可以将其粘贴到 Cursor 聊天窗口中,人工智能通常会对其进行分析并提出修复建议。这使得调试变成了一种协作体验:与其手动搜索 Google 或 Stack Overflow,Cursor 的 AI 通常可以精确定位问题,甚至编写补丁。不过,验证这些修复仍然很重要,因为 AI 并非总能一次成功。
Cursor also excels at understanding errors and logs. If you run your code and get a traceback or error message, you can paste it into the Cursor chat, and often the AI will analyze it and suggest a fix. This turns debugging into a cooperative experience: rather than you manually searching Google or Stack Overflow, Cursor’s AI can often pinpoint the problem and even write the patch. That said, it’s wise to verify the fixes, as the AI might not always get it right on the first try.
另一个专业技巧:利用 Cursor 的跨文件处理功能。您可以选择一组文件(或在提示中告知项目上下文),以便它在生成代码时考虑您的整个代码库。例如:在后端添加一个新的 API 端点以支持登录表单,并将其连接到我们刚刚创建的前端表单。Cursor 会调用它刚刚编写的前端代码,并帮助您构建相应的后端逻辑。与之前只能逐个文件运行的代码助手相比,这种项目级上下文功能可谓是颠覆性的。
Another pro tip: use Cursor’s ability to take multiple files into account. You can select a set of files (or let it know about project context in the prompt) so that it considers your whole codebase when generating code. For example: add a new API endpoint in the backend to support the login form, and connect it to the frontend form we just made. Cursor will recall the frontend code it just wrote and help craft the corresponding backend logic. This project-wide context is a game changer compared to earlier coding assistants that only worked file by file.
总而言之,Cursor 就像一个 24/7 全天候驻留在 IDE中的AI 结对程序员。它非常直观(你可以用简单的语言与它交流),并且可以直接更新你的代码。你越是练习将任务分解并用清晰的指令提示 Cursor,就越能发现自己能在短时间内完成更多的工作。它尤其适合迭代开发:你先构建一部分代码,运行并查看输出,然后立即让 Cursor 调整或扩展代码,如此循环往复。
In summary, Cursor is like having an AI pair programmer inside your IDE, 24/7. It’s intuitive (you chat with it in plain language), and it can update your code directly. The more you practice breaking down tasks and prompting Cursor with clear instructions, the more you’ll find you can accomplish in a short time. It’s particularly great for iterative development: you build a bit, run and see output, then immediately ask Cursor to adjust or extend the code, and repeat.
又一颗冉冉升起的新星氛围编码工具箱是 Windsurf,这是一个人工智能驱动的开发环境,可将代码理解提升到一个新的水平。Windsurf 由Codeium 背后的团队打造,其独特之处在于它会对你的整个代码库进行索引,并在你工作时利用检索技术将相关代码片段提供给 AI 模型。实际上,这意味着 Windsurf 非常擅长处理大型项目,即使问题的答案分散在多个文件中。它的核心使用了一种叫做检索增强生成(RAG)的技术,这是一种比较花哨的说法,意思是它会查找代码中与你的提示相关的部分,并将该上下文提供给人工智能,以便其建议与你现有的代码保持一致。
Another rising star in the vibe-coding toolbox is Windsurf, an AI-driven development environment that takes code understanding to the next level. Windsurf is built by the team behind Codeium, and it differentiates itself by indexing your entire codebase and using retrieval techniques to feed the relevant pieces to the AI model as you work. In practical terms, this means Windsurf is extremely good at handling large projects where the answer to your question might be spread across many files. Its core uses something called retrieval-augmented generation (RAG), which is a fancy way of saying it looks up the parts of your code that are relevant to your prompt and provides that context to the AI so that its suggestions are consistent with your existing code.
这对开发者来说意味着什么?假设你刚接触一个大型代码库,需要添加一个功能。使用 Windsurf,你可以用自然语言提问:
What does this look like for a developer? Let’s say you’re new to a big codebase and need to add a feature. With Windsurf, you can ask in natural language:
用户身份验证逻辑在代码库的哪个位置处理?
Where in the codebase is the user authentication logic handled?
它会搜索整个它会建立索引并指向正确的文件甚至函数。然后,你可以打开一个聊天窗口(Windsurf 称之为“级联视图”,可通过 Cmd+L 触发),并说:
It will search through the index and point you to the right file or even function. Then, you might open a chat (Windsurf calls it the “Cascade” view, triggered by Cmd+L) and say:
在登录流程中添加基于手机的双因素身份验证。
Add a phone-based two-factor authentication to the login flow.
因为 Windsurf 了解您的身份验证逻辑,所以它可以生成跨多个文件(数据库、API、前端)的更改来实现此功能,从而做出与您的系统结构相符的明智选择。
Because Windsurf has the context of your auth logic, it can generate changes spanning multiple files (database, API, frontend) to implement this, making informed choices that line up with how your system is structured.
Windsurf 的写入模式可以大胆地为您应用更改:它会自动创建新文件或编辑现有文件,而不仅仅是在侧边栏中显示差异建议。这可以节省大量时间:您无需从建议中复制粘贴,即可看到项目在原地不断演进。Windsurf 本质上会在确信无误时代表您执行操作,就像一位自主的初级开发人员在代码库中实现各种功能一样。(Cursor 的理念则更为保守,会要求您确认,尽管其专业版也具备“自动应用”功能。)
Windsurf’s Write mode can boldly apply changes for you: it will create new files or edit existing ones automatically rather than just suggesting diffs in a sidebar. This can be a huge time-saver: instead of copy-pasting from suggestions, you see your project evolving in place. Windsurf essentially tries to take actions on your behalf when it’s confident, behaving like an autonomous junior dev implementing features across the codebase. (Cursor’s philosophy is a bit more conservative, asking for confirmation, although its Pro version has an “auto-apply” feature too.)
To leverage Windsurf effectively, it helps to understand its strengths:
你几乎可以用纯英语查询你的代码库。就像为你的项目定制一个 Stack Overflow 一样。这对于大型遗留项目来说非常有用,因为在这些项目中,查找某个代码的定义位置可能需要花费数小时。Windsurf 可以通过从索引代码中提取信息,在几秒钟内给出答案。
You can query your codebase in plain English, almost like a custom Stack Overflow for your project. This is great for large legacy projects where finding where something is defined can take hours. Windsurf will answer in seconds by pulling from the indexed code.
因为它提供了相关信息Windsurf 可以将文件导入模型,并很好地处理诸如“重构支付模块以使用我们编写的新日志记录实用程序”之类的任务,因为它既了解支付模块又了解日志记录实用程序。
Because it feeds relevant files into the model, Windsurf can handle tasks like “Refactor the payment module to use the new logging utility we wrote” very well, as it knows about both the payment module and the logging utility.
Windsurf 有多种模式(如前面提到的自动完成、聊天、命令和级联)。Cascade 类似于超级聊天,可以考虑更广泛的上下文。“写入模式”(在聊天窗口中)会实际执行更改。作为工程师,您可以决定赋予它多大的自主权。
Windsurf has multiple modes (Autocomplete, Chat, Command, and Cascade, as mentioned). The Cascade is like a superchat, where it can consider a broader context. The Write mode (within chat) actually executes changes. You, as the engineer, can decide how much autonomy to give it.
对于团队而言,Windsurf 可以像 Cursor 一样轻松集成到日常开发中。在两者之间进行选择时,一些开发者更倾向于 Windsurf,因为它速度更快、响应更灵敏(他们指出 Windsurf 生成和应用更改的速度更快),而且由于其索引功能,Windsurf 更适合处理大型项目。另一方面,Cursor 的界面可能更符合 VSCode 用户的使用习惯。这并非非此即彼的选择——有些工程师会同时使用两者,或者团队可能会选择其中一种作为标准。
For a team, Windsurf can be integrated into daily development much like Cursor. When picking between them, some developers prefer Windsurf for its speed and boldness (noting that it feels faster to generate and apply changes) and for working with very large projects due to its indexing. On the other hand, Cursor’s interface might feel more familiar to VSCode users. It’s not necessarily an either/or choice—some engineers keep both handy, or teams might standardize on one.
总而言之,如果您想要一个真正能在编写代码前“阅读文档/代码”的AI编码助手,Windsurf绝对是您的理想之选。它能自动查找信息,最大限度地减少出现莫名其妙的函数或变量命名错误的情况。为了充分发挥其效用,您可以提供清晰的指令,让它在“写入模式”下处理大型任务;但对于细微的修改,您也可以更谨慎地使用它。务必检查它所做的更改(它会显示给您),尤其是关键代码。Windsurf很智能,但并非完美无缺。如果使用得当,它就像一个超级智能的IDE,了解您的整个项目,并能将您的想法应用到整个项目中,从而显著提升您的开发效率。
In sum, Windsurf is an excellent tool if you want an AI coding assistant that truly “reads the docs/code” before writing. It minimizes the chances of hallucinated functions or misnamed variables because it can look things up. To get the most out of it, feed it clear instructions and let it rip in Write mode for big tasks, but also feel free to use it in a more controlled fashion for delicate changes. Always review the changes it makes (it will show them to you), especially for critical code. Windsurf is smart, but it’s not infallible. Used wisely, it’s like a hyperintelligent IDE that knows your entire project and can implement ideas across it, giving a serious boost to your throughput.
人工智能编码格局已经发生了改变。形势急剧恶化,目前多款功能强大的机型正在争夺开发者的注意力,其中包括 Claude、Gemini 和OpenAI家族。 过去可能只有一种模型占据主导地位,而如今的生态系统提供了丰富的选择,每种模型都有其独特的优势,使其适用于不同的编码场景。
The AI coding landscape has transformed dramatically, with multiple powerful models now competing for developers’ attention, including models from the Claude, Gemini, and OpenAI families. Where once a single model might have dominated, today’s ecosystem offers a rich selection of options, each with distinct strengths that make them suitable for different coding scenarios.
当今的编码模型通常低于根据其方法和优势,可将其分为以下几类:
Today’s coding models generally fall into several categories based on their approach and strengths:
These prioritize quick responses and are ideal for real-time code completion and rapid iteration. They typically offer lower latency at the cost of slightly reduced accuracy on complex tasks.
这些问题需要更多时间来“仔细思考”。 但擅长复杂调试、架构决策和多步骤问题解决。具备高级推理能力的模型可以逐步分解复杂的错误。
These take more time to “think through” problems but excel at complex debugging, architectural decisions, and multistep problem solving. Models with advanced reasoning capabilities can break down complex bugs step-by-step.
有些模型不仅可以处理代码和文本,还可以处理图像、图表,甚至视频内容。这使得它们对于理解视觉文档或处理 UI/UX 元素特别有价值。
Some models can process not just code and text but also images, diagrams, and even video content. This makes them particularly valuable for understanding visual documentation or working with UI/UX elements.
DeepSeek 的突出之处在于提供它拥有与闭源模型相当的人工智能能力,无需付费或注册,但可能缺少一些功能,例如图像生成或网页浏览功能。
DeepSeek stands out by offering a comparable level of AI power to closed-source models without requiring payment or sign-up, though it may lack some features like image generation or web browsing capabilities.
与其寻找单一的“最佳”模式,不如寻找成功的模式开发人员现在将模型与特定任务相匹配:
Rather than seeking a single “best” model, successful developers now match models to specific tasks:
对于快速原型制作和一般编码,针对速度和广泛语言支持进行优化的模型效果很好。
For rapid prototyping and general coding, models optimized for speed and broad language support work well.
对于复杂的调试和系统设计,能够有条不紊地追踪逻辑的深度推理模型是一个不错的选择。
For complex debugging and system design, deep reasoning models that can trace through logic methodically are a good choice.
对于大型代码库,选择具有广泛上下文窗口的模型,以便保持项目范围内的感知。
For working with large codebases, choose models with extensive context windows that can maintain project-wide awareness.
对于预算有限的团队来说,开源模式无需订阅费用即可提供极佳的价值。
For budget-conscious teams, open source models provide excellent value without subscription costs.
现在许多工具都支持多种 AI 模型,包括 OpenAI、Claude 和 Gemini 的变体,以及专有模型,允许开发人员根据手头的任务在它们之间进行切换。
Many tools now support multiple AI models, including OpenAI, Claude, and Gemini variants, along with proprietary models, allowing developers to switch between them based on the task at hand.
无论你选择哪种人工智能模型,某些做法都能持续提升结果。首先,提供丰富的上下文信息。不要仅仅提出“支付处理功能”的要求。相反,请分享您的数据模型、现有代码模式、错误处理方法以及任何具体需求。您提供的背景信息越多,最终生成的代码就越能与您的代码库相匹配。
Regardless of which AI model you choose, certain practices consistently improve results. First, provide rich context. Don’t just ask for “a payment processing function.” Instead, share your data models, existing code patterns, error-handling approaches, and any specific requirements. The more context you provide, the better the output will align with your codebase.
大多数现代编码模型都擅长自我审查其输出。在收到生成的代码后,请模型检查潜在问题、提出改进建议或解释其推理过程。这种自我审查通常可以发现一些不易察觉的错误或提出优化建议。
Most modern coding models excel at reviewing their own output. After receiving generated code, ask the model to check for potential issues, suggest improvements, or explain its reasoning. This self-critique often catches subtle bugs or suggests optimizations.
利用模型维护对话上下文的功能。先从基本实现入手,然后通过后续请求逐步完善。这种迭代方法通常比一开始就试图指定所有内容效果更好。
Use the model’s ability to maintain conversation context. Start with a basic implementation, then progressively refine it through follow-up requests. This iterative approach often yields better results than trying to specify everything up front.
每种模型在解决问题的方式上都有一些细微的差别。有些模型的解释比较冗长,而有些则更简洁。有些模型默认使用较新的语法,而有些则更倾向于保守的语法。了解这些倾向有助于你设计出更好的提示。
Each model has subtle differences in how it approaches problems. Some are more verbose in their explanations, while others are more concise. Some default to newer syntax, while others play it safe. Learning these tendencies helps you craft better prompts.
人工智能编码领域每月都在不断发展变化,新的模型不断挑战着现有的领先者。竞争日趋激烈,开发者们因此拥有了前所未有的选择和能力提升。最重要的不是选择“完美”的模型,而是了解如何充分利用现有工具的优势。
The AI coding landscape evolves monthly, with new models regularly challenging established leaders. The competition has become so intense that developers benefit from unprecedented choice and capability improvements. What matters most isn’t picking the “perfect” model but understanding how to leverage the strengths of whatever tools are available.
现在许多开发团队都采用组合式方法——利用快速模型处理日常任务,利用功能强大的模型应对复杂挑战,并利用专用模型处理特定领域,例如数据库优化或前端开发。一些集成开发环境甚至允许在任务进行过程中无缝切换模型。
Many development teams now use a portfolio approach—leveraging fast models for routine tasks, powerful models for complex challenges, and specialized models for specific domains like database optimization or frontend development. Some IDEs even allow seamless switching between models midtask.
成功之道在于理解这些选项,并策略性地运用它们来加速您的开发工作流程。
Success comes from understanding these options and strategically applying them to accelerate your development workflow.
谷歌的 Gemini系列产品凭借其原生多模态功能,代表了人工智能辅助开发领域的一次根本性转变。与主要基于文本和代码训练的模型不同,Gemini 从一开始就被设计成能够无缝理解和处理文本、代码、图像、视频和其他数据格式。这使其在现代开发工作流程中表现得异常强大,因为在这些工作流程中,视觉上下文与文本信息同样重要。
Google’s Gemini family represents a fundamental shift in AI-assisted development through its native multimodal capabilities. Unlike models that were primarily trained on text and code, Gemini was architected from the ground up to seamlessly understand and work across text, code, images, video, and other data formats. This makes it exceptionally powerful for modern development workflows where visual context matters as much as textual information.
Gemini 的多模态特性在 Web 开发场景中尤为宝贵。开发者可以分享设计稿的截图,Gemini 能够生成与视觉风格完全匹配的像素级精确实现。它尤其擅长理解图表、示意图和 UI 元素,是视觉设计转化为功能代码的理想伙伴。这种能力远不止于简单的图像识别:Gemini 能够推理视觉元素、理解设计模式,并在整个项目中保持美学上的一致性。
The multimodal nature of Gemini proves particularly valuable in web development scenarios. Developers can share screenshots of design mockups, and Gemini can generate pixel-perfect implementations that match the visual style. It excels at understanding charts, diagrams, and UI elements, making it an ideal partner when translating visual designs into functional code. This capability extends beyond simple image recognition: Gemini can reason about visual elements, understand design patterns, and maintain aesthetic consistency across an entire project.
Gemini与开发工作流程的集成通过流行的编辑器(VSCode、Cursor、Windsurf)和插件(如 Cline 和 Code Assist),开发者可以拥有强大的自定义选项,这些选项可以从个人偏好扩展到团队标准。开发者可以为重复性任务创建自定义命令,建立适用于每次代码生成的规则,并在大型代码库中保持一致的编码模式。慷慨的免费版本使其能够被学生、业余爱好者和初创公司所接受,而企业级功能则可满足复杂的组织需求。
Gemini’s integration with development workflows through popular editors (VSCode, Cursor, Windsurf) and plug-ins like Cline and Code Assist offers developers powerful customization options that scale from individual preferences to team-wide standards. Developers can create custom commands for repetitive tasks, establish rules that apply to every code generation, and maintain consistent coding patterns across large codebases. The generous free tier makes it accessible to students, hobbyists, and startups, while enterprise features support complex organizational requirements.
Gemini 在编程领域脱颖而出的原因在于它能够在保持高效运行的同时,深入思考问题。该模型能够根据具体问题灵活切换:对于简单任务快速响应,对于复杂挑战则进行深入推理。这种灵活性,结合其强大的可视化理解能力,使其在全栈开发中尤为有效,因为在全栈开发中,后端逻辑和前端美学都至关重要。
What distinguishes Gemini in the coding landscape is its ability to think deeply about problems while maintaining practical speed. The model can alternate between quick responses for simple tasks and extended reasoning for complex challenges, adapting its approach based on the problem at hand. This flexibility, combined with its visual understanding capabilities, makes it particularly effective for full stack development where both backend logic and frontend aesthetics matter equally.
Anthropic Claude 的编码辅助方法以透明度和深度推理能力为中心。Claude 系列,特别是 Sonnet 模型,已经证明自己在需要仔细分析和逐步解决问题的复杂软件工程任务方面具有非凡的能力。Claude 的独特之处在于它能够展示其思考过程,使开发人员能够跟随其推理过程并验证其逻辑,然后再实施解决方案。
Anthropic Claude’s approach to coding assistance centers on transparency and deep reasoning capabilities. The Claude family, particularly the Sonnet models, has established itself as exceptionally capable at complex software engineering tasks that require careful analysis and step-by-step problem solving. What sets Claude apart is its ability to show its thinking process, allowing developers to follow along with its reasoning and verify its logic before implementing solutions.
文物功能代表了一种开发者与AI代码助手交互方式的范式转变。Claude不再只是在聊天界面中提供代码,而是创建了一个专属的工作空间,用户可以在这里实时查看、编辑和预览代码。这种交互式环境对于前端开发、数据可视化以及任何需要即时视觉反馈来加速开发流程的场景都尤为强大。开发者可以在同一对话中迭代设计、测试功能并改进实现。
The Artifacts feature represents a paradigm shift in how developers interact with AI coding assistants. Rather than simply providing code in a chat interface, Claude creates a dedicated workspace where code can be viewed, edited, and previewed in real time. This interactive environment is particularly powerful for frontend development, data visualization, and any scenario where immediate visual feedback accelerates the development process. Developers can iterate on designs, test functionality, and refine implementations all within the same conversation.
Claude 在实际软件工程基准测试中表现出色,在缺陷修复、功能实现和代码重构等任务中始终名列前茅。它的优势不仅在于生成代码,更在于理解软件项目的更广泛背景。Claude 可以分析现有代码库,识别模式和反模式,提出架构改进建议,并确保与既定的编码风格保持一致。这使得它对于全新项目和遗留系统维护都极具价值。
Claude demonstrates exceptional performance on real-world software engineering benchmarks, consistently ranking among the top models for tasks like bug fixing, feature implementation, and code refactoring. Its strength lies not just in generating code but in understanding the broader context of software projects. Claude can analyze existing codebases, identify patterns and antipatterns, suggest architectural improvements, and maintain consistency with established coding styles. This makes it invaluable for both greenfield projects and legacy system maintenance.
该模型的内存和上下文管理方法使其能够在长时间的编码过程中逐步建立理解。在处理大型项目时,Claude 可以提取并保留有关代码库结构、设计决策和项目特定模式的关键信息。随着开发的推进,这些积累的知识使其能够提供越来越相关且更具上下文意义的建议,使其更像是一个随着时间推移逐渐熟悉项目的团队成员,而不是一个没有状态的助手。
The model’s approach to memory and context management enables it to build understanding over extended coding sessions. When working with large projects, Claude can extract and retain key information about the codebase structure, design decisions, and project-specific patterns. This accumulated knowledge allows it to provide increasingly relevant and contextual suggestions as development progresses, making it feel more like a team member who grows familiar with the project over time rather than a stateless assistant.
ChatGPT已成为人工智能编码助手领域的瑞士军刀,其价值不在于其专业功能,而在于其卓越的多功能性和广泛的知识库。它在开发者工具包中的定位独树一帜。其他模型可能直接集成到集成开发环境 (IDE) 中,或提供专门的编码环境,而 ChatGPT 则像一个随时可用的编程顾问,开发者可以在整个工作日将其保持在浏览器中打开的状态。
ChatGPT has established itself as the Swiss Army knife of AI coding assistants, valued not for specialized features but for its remarkable versatility and broad knowledge base. Its position in the developer toolkit is unique. While other models might integrate directly into IDEs or offer specialized coding environments, ChatGPT serves as an always available programming consultant that developers keep open in their browsers throughout the workday.
ChatGPT 的对话式界面使其在探索性问题解决和学习方面异常高效。开发者经常使用它进行模拟调试,粘贴问题代码,并在自然对话中思考问题。其广泛的训练使其能够识别几乎所有常用编程语言、框架和工具中的模式。无论是调试正则表达式、理解晦涩的错误信息,还是探索陌生的库文档,ChatGPT 都能从其全面的知识库中提供相关的见解。
The conversational interface of ChatGPT makes it exceptionally effective for exploratory problem solving and learning. Developers regularly use it for rubber-duck debugging, pasting in problematic code and thinking through issues in natural conversation. Its extensive training enables it to recognize patterns across virtually every programming language, framework, and tool in common use. Whether debugging a regex expression, understanding an obscure error message, or exploring unfamiliar library documentation, ChatGPT can provide relevant insights drawn from its comprehensive knowledge base.
ChatGPT 的优势在于它能够弥合人类意图和代码实现之间的差距。它擅长双向翻译——能够将自然语言描述转换为可运行的代码,并用通俗易懂的英语解释复杂的代码。这使其在文档编写、代码审查和团队内部知识转移方面具有不可估量的价值。开发人员可以粘贴不熟悉的代码并获得对其功能的清晰解释,或者描述期望的行为并获得适用于多种编程范式的相应实现。
ChatGPT’s strength lies in its ability to bridge the gap between human intent and code implementation. It excels at bidirectional translation—converting natural language descriptions into working code and explaining complex code in plain English. This makes it invaluable for documentation, code reviews, and knowledge transfer within teams. Developers can paste unfamiliar code and receive clear explanations of its functionality, or describe desired behavior and receive appropriate implementations across multiple programming paradigms.
该模型的通用性不仅限于传统编程语言,还涵盖配置文件、脚本、数据格式和领域特定语言。虽然专业的编码工具在其专注领域内表现出色,但 ChatGPT 却能为整个软件开发任务提供宝贵的帮助。这种广度使其在处理不同技术交叉领域或遇到跨领域问题时尤为有用。它能够在长时间的对话中保持上下文关联,使开发人员能够迭代地探索复杂问题,并通过协作对话不断完善解决方案。
The model’s versatility extends beyond traditional programming languages to configuration files, scripts, data formats, and domain-specific languages. While specialized coding tools excel within their focused domains, ChatGPT provides valuable assistance across the entire spectrum of software development tasks. This breadth makes it particularly useful when working at the boundaries between different technologies or when encountering problems that span multiple domains. Its ability to maintain context across extended conversations allows developers to explore complex problems iteratively, refining solutions through collaborative dialogue.
这些功能强大的AI编码助手的出现,标志着软件开发实践的根本性转变。成功的开发商并不将它们视为相互竞争的选择,而是认识到每个车型系列都能在开发过程的不同方面带来独特的优势。Google 的 Gemini 在视觉上下文和多模态理解至关重要时表现出色,尤其是在 UI/UX 开发和处理设计规范时。 Anthropic 的 Claude 模型在需要深度推理、复杂重构和透明问题解决方法的场景中表现出色。OpenAI 模型家族拥有无与伦比的多功能性和广博的知识,使其成为学习、调试和跨领域挑战的理想之选。
The availability of these powerful AI coding assistants represents a fundamental shift in software development practices. Rather than viewing them as competing options, successful developers recognize that each model family brings unique strengths to different aspects of the development process. Google’s Gemini excels when visual context and multimodal understanding are crucial, particularly in UI/UX development and when working with design specifications. Anthropic’s Claude shines in scenarios requiring deep reasoning, complex refactoring, and transparent problem-solving approaches. The OpenAI family of models provides unmatched versatility and broad knowledge, making it ideal for learning, debugging, and cross-domain challenges.
现在许多开发团队采用组合式方法,针对同一项目中的不同任务利用不同的模型。典型的工作流程可能包括使用 Gemini 将设计模型转化为初始实现,使用 Claude 进行复杂的架构决策和代码审查,以及使用 ChatGPT 进行一般性问题解决和文档编写。这种多模型方法通过将每种工具的优势与特定的开发挑战相匹配,最大限度地提高了生产力。
Many development teams now employ a portfolio approach, leveraging different models for different tasks within the same project. A typical workflow might involve using Gemini to translate design mockups into initial implementations, Claude for complex architectural decisions and code reviews, and ChatGPT for general problem solving and documentation. This multimodel approach maximizes productivity by matching each tool’s strengths to specific development challenges.
随着这些模型的不断发展,有效人工智能辅助开发的关键不在于选择一个“最佳”方案,而在于了解如何协调多个人工智能助手,以加速和增强软件开发生命周期的各个方面。
As these models continue to evolve, the key to effective AI-assisted development lies not in choosing a single “best” option but in understanding how to orchestrate multiple AI assistants to accelerate and enhance every aspect of the software development lifecycle.
这个生态系统尚处于起步阶段,且变化迅速。每隔几个月就会涌现出新的参与者和功能。关键在于,你无需从零开始构建自己的人工智能,就能利用意图编程——市面上有很多工具可以让你轻松掌握这种能力。本书中,我将探讨各种平台以及它们如何融入“意图编程”工作流程。
This ecosystem is young and rapidly changing. New players and capabilities are emerging every few months. The key takeaway is that you don’t have to build your own AI from scratch to leverage programming with intent—there are plenty of tools that bring this power to your fingertips. Throughout this book, I’ll discuss various platforms and how they fit into the vibe-coding workflow.
重要的是要认识到人工智能辅助开发真正发挥作用的场景,以及它可能仍然会失败的场景。让我们来探讨一些氛围编码表现出色的理想用例,以及当今人工智能仍然面临挑战或需要大量人工干预的情况。
It’s important to recognize the scenarios where AI-assisted development truly shines—and where it might still fall flat. Let’s explore some ideal use cases where vibe coding excels, as well as situations where today’s AI still struggles or requires heavy human intervention.
就像某些架构适合解决某些问题一样,氛围在软件开发领域,编码有其“优势领域”。
Just as certain architectures are suited for certain problems, vibe coding has its “sweet spots” in the software development landscape.
Vibe 编码对于启动一个全新的项目来说是一项颠覆性的技术。“从零到一” (由彼得·蒂尔推广)指的是从零开始创造新事物。借助人工智能,您可以以闪电般的速度从空白画布生成功能原型。需要搭建一个前所未有的 Web 应用?只需快速提示,即可生成前端、后端、数据库架构甚至部署脚本的样板代码。这对于初创公司或黑客马拉松项目来说堪称完美,因为它们的目标是快速验证想法。无需花费数周时间搭建项目的“脚手架”(所有重复的设置代码),人工智能只需几分钟即可完成。
Vibe coding is a game changer for getting a brand-new project off the ground. The term zero to one (popularized by Peter Thiel) refers to creating something new from scratch. With AI, you can go from a blank canvas to a functional prototype at lightning speed. Need to stand up a web app that’s never existed before? You can generate boilerplate code for your frontend, backend, database schema, and even deployment scripts in one frenetic session of prompting. This is perfect for startups or hackathon projects where the goal is to validate an idea quickly. Instead of spending weeks setting up the “scaffolding” of a project (all the repetitive setup code), you can have the AI do it in minutes.
许多开发者他们讲述了如何在人工智能结对程序员的帮助下,利用一个周末的时间构建出一个最小可行产品(MVP)——这在以前可能需要他们独自工作一个月的时间。通过快速将想法转化为可运行的产品,您可以更快地开始与用户或利益相关者进行测试。人工智能非常擅长处理通用任务(例如设置路由、基本用户界面组件、标准CRUD操作),这让您可以专注于产品的创新之处。
Many developers have recounted how they built an MVP over a weekend with the help of AI pair programmers—something that might have taken them a month working solo before. By quickly materializing the idea into a working product, you can start testing it with users or stakeholders much sooner. The AI is great at the generic stuff (setting up routing, basic UI components, standard CRUD operations), which frees you to focus on the novel aspects of your product.
然而,一旦你的最小可行产品(MVP)获得市场认可并投入生产,你的方法就必须转变。这时,人工智能辅助工程就显得至关重要。虽然直觉式编码能够帮助你快速探索和验证,但如今规模化需要更加严谨的实践。你需要重构那些快速生成的代码,添加适当的错误处理,增加全面的测试覆盖,并建立清晰的架构边界。从原型到产品的过渡标志着从直觉式编码的探索自由向工程的结构化规范的自然演进。优秀的团队会意识到这个转折点,并相应地调整人工智能的使用——在保持速度的同时,引入可持续增长所需的保障措施。
However, once your MVP gains traction and moves toward production, your approach must shift. This is where AI-assisted engineering becomes essential. While vibe coding has helped you explore and validate quickly, scaling now requires more deliberate practices. You’ll need to refactor that rapidly generated code with proper error handling, add comprehensive test coverage, and establish clear architectural boundaries. The transition from prototype to product marks the natural evolution from vibe coding’s exploratory freedom to engineering’s structured discipline. Smart teams recognize this inflection point and adjust their AI usage accordingly—maintaining velocity while introducing the guardrails necessary for sustainable growth.
很多软件工程,尤其是商业应用程序,都涉及围绕数据的 CRUD(创建、读取、更新、删除)功能。这是人工智能非常擅长的公式化工作,因为它已经见过无数的例子。例如,如果你需要在系统中添加一个新的“库存”模块,并包含 CRUD 界面和 API,Vibe Code 就能出色地完成这项任务。它可以生成数据库迁移、ORM 模型、API 端点和带有验证功能的 UI 表单——基本上涵盖了整个技术栈——而且几乎不会出错,因为这些模式在其训练数据中非常常见。即使你的应用有自定义规则,你也可以在提示中指定这些规则,并获得不错的初步结果。结果是:原本需要一周时间才能完成的枯燥的配置工作,现在只需一个下午的提示和测试即可完成。对于内部工具或管理面板(本质上也是大型 CRUD 应用),考虑到它们通常既简单又耗时,你几乎可以完全依赖人工智能来生成它们。
A lot of software engineering, especially in business apps, involves CRUD—create, read, update, delete—functionality around data. This is formulaic work that AI is exceptionally good at because it’s seen countless examples. If you need to add, say, a new “Inventory” module to your system with CRUD screens and APIs, vibe coding will handle that extremely well. It can produce database migrations, ORM models, API endpoints, and UI forms with validation—basically the full stack—largely error-free because these patterns are so common in its training data. Even if your app has custom rules, you can specify those in a prompt and get a decent first pass. The result: what used to be a week-long task of boring wiring-up becomes an afternoon of prompting and testing. For internal tools or admin panels (which are essentially big CRUD apps), you might almost entirely lean on AI to generate them, given how straightforward yet time-consuming they normally are.
工程方法变得至关重要当这些 CRUD 操作涉及复杂的业务逻辑、数据验证规则或与现有系统的集成时,虽然 Vibe 编码可以快速生成基本结构,但 AI 辅助工程可以确保您的库存模块能够正确处理并发更新等极端情况,维护引用完整性,并遵循您组织既定的模式。例如,您可以使用 Vibe 编码生成初始的 CRUD 框架,然后切换到工程模式来实现特定领域的规则,例如库存阈值警报、多仓库分配逻辑或与现有身份验证和授权系统的集成。关键在于识别何时从快速生成过渡到精细化完善。
The engineering approach becomes crucial when these CRUD operations involve complex business logic, data validation rules, or integration with existing systems. While vibe coding can generate the basic structure quickly, AI-assisted engineering ensures that your inventory module properly handles edge cases like concurrent updates, maintains referential integrity, and follows your organization’s established patterns. For instance, you might use vibe coding to generate the initial CRUD scaffolding, then switch to engineering mode to implement domain-specific rules like inventory threshold alerts, multiwarehouse allocation logic, or integration with your existing authentication and authorization systems. The key is recognizing when to transition from rapid generation to careful refinement.
需要将两个服务或 API 集成在一起?这通常需要阅读文档并编写代码,将数据从一种格式转换为另一种格式。AI 模型通常基于 API 文档和代码示例进行训练,这意味着它们可以加快集成工作。例如,您可以让 ChatGPT 演示如何从语言B调用服务 A 的 API ,它很可能会生成包含正确端点的示例代码,甚至可能还会提供身份验证示例。当 AI 能够建议需要处理的样板代码和特殊情况时,集成多个系统(例如将支付网关与订单系统连接或连接第三方分析 SDK)就变得更加容易。它尤其擅长这些标准集成模式。
Need to integrate two services or APIs together? That often involves reading docs and writing code to transform data from one format to another. AI models have often been trained on API documentation and code examples, meaning they can expedite integration work. Ask ChatGPT to show how to call Service A’s API from Language B—chances are it will produce example code with the right endpoints and maybe even an auth example. Combining multiple systems (like hooking up a payment gateway with your order system or connecting a third-party analytics SDK) becomes easier when the AI can suggest the boilerplate and edge cases to handle. It excels at these standard integration patterns.
人工智能编码助手拥有有效地阅读所有流行框架的手册:React、Angular、Django、Rails、Node/Express、Flutter——等等。这意味着,如果您使用知名框架,AI 可以生成符合这些框架规范的代码。例如,它可以生成带有 Hooks 和状态管理的 React 组件,或者带有正确 admin 类和序列化的 Django 模型。好处在于您无需记住每个细节——AI 会填补空白。Vibe Codeing 在处理现代 Web 开发任务方面表现尤为出色,例如生成带有正确类的 HTML/JSX 或连接控制器端点,因为这些都是 AI 模型反复遇到的任务。这就像身边始终有一位框架专家,在您确定功能具体实现方式时,他会帮您编写样板代码。
AI coding assistants have effectively read the manuals on all popular frameworks: React, Angular, Django, Rails, Node/Express, Flutter—you name it. This means that if you’re using well-known frameworks, the AI can generate idiomatic code for those frameworks. For instance, it can spit out a new React component with hooks and state management or a new Django model with the proper admin class and serializer. The benefit is you don’t have to remember every little detail—the AI fills in the gaps. Vibe coding performs especially well with modern web development tasks like generating HTML/JSX with the right classes or hooking up controller endpoints, because these are tasks AI models have seen over and over. It’s like having a framework expert always by your side to write the boilerplate while you decide on the specifics of what the feature should do.
有时你需要创建很多类似的代码(例如,某些模式中每种类型都需要创建许多类似的端点或类)。对人类来说,这可能既繁琐又容易出错。而人工智能则喜欢重复的结构——只要给它一两个例子,它就能持续不断地生成其余的例子。批量代码生成可以节省大量时间。例如,如果您要为 50 种类型的记录编写数据模型类,您可以提供一个示例,然后让 AI 根据该模式生成所有 50 种类型的类。它很可能在几秒钟内完美地完成这项工作。结果就是:您可以避免一整天单调乏味的编码工作。
Sometimes you need to create lots of similar code (like many similar endpoints or classes for each type in some schema). This can be tedious and error-prone for a human. AI, on the other hand, loves repetitive structures—once you show it one or two examples, it can churn out the rest consistently. This bulk code generation can save a ton of time. For instance, if you’re writing data model classes for 50 types of records, you can prompt one example and ask the AI to generate classes for all 50 types following that pattern. It will likely do so flawlessly and in seconds. The result: you avoid a whole day of monotonous coding.
虽然直觉式编程在某些情况下表现出色,但在其他情况下,人工智能辅助工程就变得不可或缺了。了解这些情况有助于开发人员从一开始就选择正确的方法,避免代价高昂的重写或技术债务。复杂的算法实现需要工程化的方法。构建复杂的数据结构、实现对性能要求极高的算法或解决新的计算问题时,需要对实现的每个方面进行精确控制。
While vibe coding excels in certain scenarios, AI-assisted engineering becomes indispensable in others. Understanding these situations helps developers choose the right approach from the start, avoiding costly rewrites or technical debt. Complex algorithmic implementations require the engineering approach. When you’re building sophisticated data structures, implementing performance-critical algorithms, or solving novel computational problems, you need precise control over every aspect of the implementation.
在这里,人工智能扮演的是知识渊博的助手角色,而非代码生成器。你可以请它解释算法思路或检查你的实现是否正确,但你始终对架构和优化决策拥有直接控制权。人工智能帮助你理清思路,而不是包办一切。
Here, AI serves as a knowledgeable assistant rather than a code generator. You might ask it to explain algorithmic approaches or review your implementation for correctness, but you maintain direct control over the architecture and optimization decisions. The AI helps you think through problems rather than solving them wholesale.
关键任务系统从一开始就需要严谨的工程设计。金融交易、医疗保健应用、安全基础设施和其他高风险领域无法承受随意探索式的编码方式。在这些领域,每一行代码都需要仔细斟酌、全面测试,并且通常还需要符合相关法规。人工智能可以通过推荐最佳实践、识别潜在漏洞以及帮助确保符合标准来提供辅助,但开发人员仍然对最终实现保持严格的控制。
Mission-critical systems demand engineering rigor from the outset. Financial transactions, healthcare applications, security infrastructure, and other high-stakes domains cannot afford the exploratory nature of vibe coding. In these contexts, every line of code needs careful consideration, comprehensive testing, and often regulatory compliance. AI assists by suggesting best practices, identifying potential vulnerabilities, and helping ensure compliance with standards, but the developer maintains tight control over the implementation.
这些系统的故障成本远远超过快速生成带来的速度优势。遗留系统集成面临着独特的挑战,工程规范至关重要。当处理数十年前的代码库、专有协议或存在大量技术债务的系统时,基于Vibe编码的模式匹配往往会失效。这些情况需要对现有约束有深刻的理解,精心规划集成点,并进行有条不紊的重构。人工智能可以通过解释遗留代码模式或提出现代化策略来提供帮助,但实际的实施需要只有结构化工程才能提供的精确性。
The cost of failure in these systems far outweighs any speed advantages from rapid generation. Legacy system integration presents unique challenges where engineering discipline proves essential. When working with decades-old codebases, proprietary protocols, or systems with extensive technical debt, vibe coding’s pattern matching often fails. These scenarios require deep understanding of existing constraints, careful planning of integration points, and methodical refactoring. AI can help by explaining legacy code patterns or suggesting modernization strategies, but the actual implementation requires the precision that only structured engineering provides.
性能优化是工程技术胜过人为因素的另一个领域。虽然人工智能可以快速生成功能性代码,但它很少能为性能关键路径提供最优解。诸如内存管理、缓存优化、并行处理和延迟降低等任务需要对硬件、操作系统和算法复杂度有深入的了解。在这些领域,人工智能最适合作为研究助手,帮助您探索优化技术或对不同方法进行基准测试,而您则可以做出明智的实施决策。
Performance optimization represents another domain where engineering trumps vibing. While AI can generate functional code quickly, it rarely produces optimal solutions for performance-critical paths. Tasks like memory management, cache optimization, parallel processing, and latency reduction require deep understanding of hardware, operating systems, and algorithmic complexity. Here, AI serves best as a research assistant, helping you explore optimization techniques or benchmark different approaches, while you make the informed decisions about implementation.
在这些场景中,人工智能的模式识别能力和速度与任务完美契合。本质上,Vibe 编码擅长处理编程中常见的任务(例如 CRUD 操作或典型的 Web 应用结构)以及那些能够快速试错的任务(例如原型开发、新想法的构思)。这就像拥有一个阅读过所有 GitHub 代码库的初级开发人员,他可以立即回忆起通常的实现方式,并为你编写代码以供审核。这对于快速推进项目进展至关重要。
In these scenarios, AI’s pattern recognition and speed align perfectly with the task. Essentially, vibe coding thrives on tasks that are well-trodden territory in programming (like CRUD or typical web app structures) and tasks that benefit from rapid trial and error (prototypes, new ideas). It’s like having a junior developer who has read every GitHub repo and can instantly recall how it’s usually done and write it for you to review. That’s incredibly powerful for getting things moving quickly.
现代人工智能增强型开发的艺术不在于选择一种方法而不是另一种方法,而在于认识到何时在它们之间进行转换。成功的开发者会对这些转折点培养出直觉。要开发新功能?先用“感觉编码”快速探索各种可能性。发现代码变得复杂或涉及关键系统?切换到工程模式。要为客户演示构建概念验证?“感觉编码”能帮你快速完成。要将概念验证转化为生产系统?那就需要运用工程规范了。
The art of modern AI-enhanced development lies not in choosing one approach over the other but in recognizing when to transition between them. Successful developers develop an intuition for these inflection points. Starting a new feature? Begin with vibe coding to explore possibilities quickly. Notice the code becoming complex or touching critical systems? Shift to engineering mode. Building a proof of concept for a client demo? Vibe coding gets you there fast. Converting that proof of concept into a production system? Time for engineering discipline.
这种灵活性——能够在快速探索和精心构建之间无缝切换——是真正高效的AI辅助开发者的标志。他们明白,直觉编码和AI辅助工程是工具箱中相辅相成的工具,各自适用于开发生命周期的不同阶段。他们的目标不是选择其中一方,而是策略性地运用这两种方法,从而在整个软件开发过程中最大限度地提高速度和质量。
This fluidity—the ability to move seamlessly between rapid exploration and careful construction—distinguishes truly effective AI-augmented developers. They understand that vibe coding and AI-assisted engineering are complementary tools in their toolkit, each suited for different phases of the development lifecycle. The goal isn’t to pick a side but to leverage both approaches strategically, maximizing both velocity and quality throughout the software development process.
尽管目前的AI编码工具令人印象深刻,但它们并非魔法。有些问题,人工智能仍然难以可靠地处理,通常需要人类的洞察力或传统的编程技术。了解这些局限性有助于设定合理的预期,并帮助你规划何时应该介入,何时应该重新掌控局面。
As impressive as current AI coding tools are, they are not magic. There are classes of problems that remain difficult for AI to handle reliably, often requiring human insight or traditional coding techniques. Knowing these limitations helps set the right expectations and lets you plan when to lean in versus when to take back the reins.
其局限性包括以下几点:
The limitations include the following:
如果你要处理非常复杂的算法或人工智能可能从未见过的全新问题,它可能会束手无策。例如,根据研究论文编写全新的算法,或者编写编译器或高度并发系统——这些都涉及复杂的逻辑,需要真正的理解和创造性的思维飞跃。人工智能可以尝试,但它可能会犯一些细微的错误。
If you’re dealing with very complex algorithms or novel problems that the AI likely hasn’t seen, it may flounder. For example, writing a brand-new algorithm from a research paper or doing something like writing a compiler or highly concurrent system—these involve intricate logic that requires true understanding and often creative leaps. AI can try, but it might get things subtly wrong.
在像这样的复杂领域,人工智能倾向于生成近似正确但并非完全正确的代码,这会导致大量的反复修改。正如第3章和第4章将要讨论的,人工智能很难确保最后30%左右的正确性。这与我所说的“ 70%难题”有关——人工智能可以快速完成大部分工作,但最后阶段却十分棘手。经验丰富的开发人员可能会使用人工智能为这类复杂任务生成框架或辅助函数,但核心逻辑则由他们自己编写。
In complex domains like these, the AI’s tendency to make approximately correct but not exactly correct code can lead to a lot of back-and-forth. As Chapters 3 and 4 will discuss, the final 30% or so of correctness is very hard for the AI to nail down. This is related to what I call the 70% problem—AI gets you most of the way quickly, but the last part is tough. An experienced developer might use AI to generate skeletons or helper functions for such complex tasks but do the core logic themselves.
当前的AI模型主要基于高级语言和抽象概念进行训练。如果需要进行底层位操作、为特定微控制器编写高度优化的C代码,或者生成向量化的SIMD指令,AI可能就不可靠了。它生成的代码可能看起来合理,但在硬件层面上并非真正最优,甚至可能不正确。
Current AI models are primarily trained on high-level languages and abstractions. If you need to do low-level bit-twiddling, write highly optimized C code for a specific microcontroller, or generate vectorized SIMD instructions, the AI might not be reliable. It might produce code that looks plausible but isn’t truly optimal, or even correct, on a hardware level.
同样,对于内存管理或实时性限制等问题,人工智能并没有真正的概念(它不会在脑海中模拟 CPU 缓存)。因此,对于性能关键型代码,您要么需要彻底测试人工智能的建议,要么需要手动编写这些部分。也就是说,人工智能仍然可以通过提供初始模板或解释汇编语言来提供帮助,但在这些情况下,您不能盲目信任它。
Similarly, for things like memory management or real-time constraints, the AI doesn’t have a real concept of those (it doesn’t simulate a CPU cache in its head). So for performance-critical code, you’ll want to either thoroughly test AI suggestions or write those parts manually. That said, AI might still help by providing a starting template or explaining assembly, but you cannot blindly trust it in these scenarios.
如果你使用的是一个非常新或冷门的框架,在人工智能训练期间并不存在,那么它将无法识别。在这种情况下,人工智能可能会尝试进行泛化,或者生成看似合适但实际上调用了不存在的函数(产生幻觉)或使用了过时的API版本的代码。例如,如果上个月发布了一个包含重大变更的新Web框架版本,人工智能将无法识别这些变更。它可能会给出旧版本的代码。在这种情况下,你必须参考文档,甚至可能需要通过在提示符中提供文档上下文来帮助训练人工智能(基本上是即时训练)。
If you’re using a very new or obscure framework that wasn’t around during the AI’s training, it won’t know about it. In such cases, the AI might try to generalize or might produce code that looks like it fits but actually call functions that don’t exist (hallucinations) or use outdated versions of the API. For example, if a new web framework version came out last month with breaking changes, the AI won’t know about those changes. It might give you code for the old version. In these cases, you have to fall back on documentation and perhaps even help train the AI by feeding it context from the docs within your prompt (basically teaching it on the fly).
如果你让人工智能来设计对于全新的用户界面或体验,人工智能并不擅长这种创造性的飞跃。它可以为已知模式(例如标准表单或仪表盘)生成 UI 代码,但如果您想要一个没有明确先例的创新 UI,人工智能可能无法提供令人眼前一亮的方案。它可能只是将熟悉的组件拼凑在一起。人类设计师和前端开发人员仍然非常需要构思全新的用户体验。从编码角度来看,人工智能可以快速生成一个标准的界面,但要获得那种独特的定制感,您需要引导它或进行手动调整。
If you ask AI to design a completely novel user interface or experience, it’s not great at that creative leap. It can generate UI code for known patterns (like a standard form or a dashboard), but if you want an innovative UI that doesn’t have clear precedents, the AI might not give you something inspiring. It might just stitch together familiar components. Human designers and frontend devs are still very much needed to dream up new user experiences. In coding terms, AI can make you a standard-looking interface quickly, but for that special custom feel, you’ll guide it or hand-tweak.
当需求不明确或相互矛盾时,人工智能有时会遇到困难。 除了你明确告知的指令之外,人工智能对最终目标并没有真正的理解。如果需求模糊不清(例如“提高效率”——这究竟是什么意思?),人工智能可能会错误地猜测你真正关心的是什么(例如,内存还是速度)。人类更擅长阐明意图,尤其是在与非技术利益相关者沟通时。人工智能也可能误解指令,特别是当它不了解特定领域的上下文信息(例如业务规则)时。它可能会生成一个逻辑上正确的解决方案,但由于理解上的细微差别而无法真正解决问题。
Sometimes AI struggles when requirements are implicit or contradictory. It has no true understanding of the end goal beyond what you explicitly tell it. If requirements are vague (“make it efficient”—what does that precisely mean?), the AI might guess incorrectly what you care about (memory versus speed, for instance). Humans are better at clarifying intent, especially with nontechnical stakeholders. AI can also misinterpret instructions, especially if there’s domain-specific context it’s unaware of (like business rules). It might produce a logically correct solution that doesn’t actually solve the real problem because the nuance was lost in translation.
一个很好的结合这些概念的例子是:想象一下用 Rust 开发一个新的 3D 图形引擎(复杂系统)(系统级,性能至关重要)。你有一些全新的渲染算法(独特的问题)。人工智能或许可以帮你编写一些样板代码,但核心部分你主要还是要依靠人类的智慧。人工智能或许能帮你搭建一个窗口和一个基本的渲染循环(常见任务),但对于定制的部分,你仍然需要采用传统的严谨编码方式,或许可以从人工智能那里获得一些伪代码形式的算法帮助。如果你让它优化一个汇编语言的热点循环,你就必须逐条验证指令。
A good example scenario combining these: imagine developing a new 3D graphics engine (complex system) in Rust (system-level, performance critical). You have novel algorithms for rendering (unique problems). AI could maybe help write some boilerplate, but you’d largely rely on human ingenuity for the core. The AI might get you started with setting up a window and a basic render loop (common tasks), but for the bespoke parts, you’d proceed with traditional careful coding and perhaps get some algorithmic help from AI in pseudocode form. And if you asked it to optimize a hot loop in assembly, you’d have to verify every instruction.
人工智能也缺乏真正的解决问题的能力。归根结底,它只是在进行模式匹配。因此,如果你的问题需要灵光一闪的顿悟,人工智能可能只会徒劳无功,输出一些看起来像代码但实际上无法解决问题的东西。这时,人类退后一步,进行抽象思考,或者借鉴实际经验,就能力挽狂澜。一旦你有了顿悟,就可以利用人工智能快速将其付诸实践。
AI also lacks true problem-solving insight. At the end of the day, it’s pattern matching. So if your problem requires an aha! insight, the AI might just flail around, presenting things that look like code but don’t solve it. This is where a human stepping back, thinking abstractly, or drawing on real experience can save the day. Once you have the insight, you can then use the AI to implement it quickly.
了解这些优势和劣势,才能确保你在合适的场景下运用“氛围编码”技巧。为了最大限度地提高成功率,要充分利用人工智能的优势(已知模式),并将你的创造力应用于应用程序的独特部分。同时,也要做好准备,在人工智能表现不佳的领域进行干预。例如,仔细审查它编写的任何涉及安全敏感的代码,因为它可能会遗漏一两个极端情况。
Understanding these strengths and weaknesses ensures you’ll deploy vibe-coding techniques in the right situations. To maximize success, leverage the AI for what it’s good at (the known patterns), and apply your creativity to the unique parts of your application. Be ready to intervene in those areas where AI is known to struggle. For instance, do a careful review of any security-sensitive code it writes, because it might miss an edge case or two.
利用人工智能来补充人类的优势:让它处理广度较广的部分(大量代码、样板代码),而你则负责深度部分(复杂的逻辑、架构)。在它擅长的领域,把它当作助力;而在那些更具挑战性的路段,不要害怕亲自掌舵。这样可以充分发挥双方的优势,从而获得最佳结果。在这个新时代,懂得何时使用人工智能、何时依靠人类技能,才是成为一名高效开发者的关键。
Use AI to complement human strengths: let it handle breadth (lots of code, boilerplate) while you handle depth (complex logic, architecture). Use it as a booster where it excels, and don’t be afraid to take the wheel on those tougher stretches of the road. This plays to the strengths of both and yields the best outcome. Knowing when to use AI and when to rely on human skill is what will make you a highly effective developer in this new era.
每项新技术都有其优势和不足。当我们拥抱人工智能辅助开发带来的生产力和创造力提升时,以细致入微的方式对待它至关重要。了解其局限性和优缺点。主要优点包括:
Every new technology comes with its advantages and its caveats. As we embrace the productivity and creativity boost from AI-assisted development, it’s important to approach it with a nuanced understanding of its limitations and trade-offs. Key benefits include:
项目可以从概念阶段发展到原型更快地开发出最终产品。人工智能可以瞬间生成框架代码(例如为新项目设置样板代码),这样您就可以将更多时间用于应用程序的独特部分。
Projects can move from concept to prototype to finished product more quickly. AI can generate scaffolding code (like setting up the boilerplate for a new project) in a flash, so you spend more time on the unique parts of your application.
因为尝试的成本较低(只需向人工智能描述你想要什么,就能得到一个快速草稿),所以开发者可能会更愿意进行实验。你可以通过不同的方式提示人工智能,从而测试解决问题的多种方法,然后选择最佳方案。这种迭代式的构思过程可以带来更具创意的解决方案。
Because the cost of trying something is lower (just describe what you want to the AI and get a quick draft), developers may feel freer to experiment. You can prototype multiple approaches to a problem by prompting the AI in different ways, then pick the best one. This iterative ideation can lead to more creative solutions.
法学硕士(LLM)接受的是大量编程知识的培训。它通常“知道”一些晦涩难懂的API或错误信息解决方案。实际上,它可以提出你可能没想到的解决方案或思路,从而让你更有效地解决问题。
LLMs are trained on a vast corpus of programming knowledge. It often “knows” obscure APIs or error message solutions. In practice, it can surface solutions or ideas you might not have thought of, making you a more effective problem solver.
在团队环境中,人工智能助手可以通过生成风格一致的代码来帮助执行编码标准和最佳实践。如果按照项目风格指南进行配置,它可以确保每个人的代码都遵循类似的模式。即使没有经过显式训练,AI 模型通常也能生成符合惯用语法的代码(因为它们从数百万个示例中学习而来)。这可以减少代码审查的工作量,因为其函数默认情况下看起来可能很熟悉,并且遵循常见的约定。
In team settings, an AI assistant can help enforce coding standards and best practices by generating code in a consistent style. If configured with your project’s style guide, it could ensure everyone’s code follows similar patterns. Even without explicit training, AI models often produce idiomatic code (since they learned from millions of examples). This can reduce the effort involved in code reviews, since its functions may look familiar and adhere to common conventions by default.
Some of the limitations and trade-offs to consider include:
这些模型并非完美无缺。它们生成的代码可能看起来正确,但存在一些不易察觉的错误或效率低下的问题。它们可能选择过时的方法,因为它们的训练数据中包含大量旧代码。作为开发者,你必须保持警惕。正如你不会在不理解代码的情况下从网上复制粘贴代码一样,你也不应该不加思考地接受人工智能生成的代码。本书第二部分将讨论如何全面验证和测试人工智能生成的代码。
These models are not infallible. They might produce code that looks correct but has subtle bugs or inefficiencies. They might choose an outdated approach because their training data included a lot of older code. As a developer, you must remain vigilant. Just as you wouldn’t copy-paste code from the internet without understanding it, you shouldn’t accept AI code thoughtlessly. Part II of this book will discuss techniques to validate and test AI-generated code thoroughly.
如果你的提示信息不够具体,人工智能就会……它必须猜测你的意图——而且它可能会猜错。例如,如果你告诉它“对姓名列表进行排序”,它可能默认按字母顺序排序,但也许你的意思是其他排序方式(例如按姓名长度排序)。除非你明确说明,否则人工智能无法区分。这就是为什么提示语的精确性(第二章的主题)至关重要——你将学会预判需要详细说明的内容。
If your prompt is underspecified, the AI has to guess your intent—and it might guess wrong. For example, if you tell it to “sort a list of names,” it might default to alphabetical sorting, but maybe you meant something else (like sorting by the length of the name). The AI won’t know the difference unless you clarify it. This is why specificity in prompts (Chapter 2’s topic) is vital—you’ll learn to anticipate what details you need to spell out.
如果新开发者总是依赖于人工智能写作他们的代码,能否培养出对算法和调试同样深刻的理解?这存在技能退化的风险,就像依赖GPS导航可能会削弱你的方向感一样。为了避免这种情况,重要的是将人工智能作为学习工具(注意它提供的代码并思考其原因),并且有时需要不借助人工智能进行编程练习,以确保你保持基本技能。
If new developers always rely on AI to write their code, will they develop the same depth of understanding of algorithms and debugging? There’s a risk of skill atrophy, similar to how relying on GPS for navigation might weaken your own sense of direction. To mitigate this, it’s important to use AI as a learning tool (pay attention to the code it provides and ask why) and sometimes practice coding without it to ensure you retain your fundamental skills.
使用基于云的技术使用人工智能编码工具通常意味着将您的代码(可能包含专有信息或敏感信息)发送给第三方服务进行分析。企业需要考虑这一点。许多工具通过允许本地部署模型或保证不存储代码来解决这个问题,但这仍然是一个需要考虑的因素。此外,人工智能还可能无意中生成与其训练数据中某些内容非常相似的代码,而这些训练数据可能采用开源许可(例如 GPL)。虽然这种情况不太可能发生(而且已有措施防止出现完全相同的输出),但这凸显了在集成人工智能之前审查和理解其生成内容的重要性。第八章将深入探讨安全性和可靠性问题。
Using cloud-based AI coding tools often means sending your code (which might be proprietary or sensitive) to a third-party service for analysis. Companies need to consider this. Many tools are addressing it by allowing on-premises models or giving assurances about not storing code, but it’s still a consideration. Also, there’s a risk that AI might inadvertently generate code that is very similar to something in its training data, which could be under an open source license (like GPL). While unlikely (and measures are in place to prevent verbatim long outputs), it highlights the need to review and understand what the AI produces before integrating it. Chapter 8 dives into questions of security and reliability.
人工智能模型会反映出训练数据中存在的偏差。在编码环境中,这可能只是偏好某些变量名,也可能很严重,例如使用假设特定用户属性的示例。例如,它可能foo/bar对所有示例变量都使用相同的名称(因为很多示例都这样做了),或者它可能对用户区域设置做出假设。与其他人工智能应用相比,这在代码生成中通常不是什么大问题,但了解这种可能性仍然值得。更微妙的是,人工智能可能会倾向于选择它更常看到的解决方案,即使这些方案并非最适合你的情况。第九章将讨论偏见和其他伦理方面的考量。
AI models can reflect biases present in their training data. In a coding context, this might be as benign as preferring certain variable names or as significant as using examples that assume particular user attributes. For instance, it might use foo/bar for every example variable (because many examples did), or it might assume things about user locales. It’s usually not a huge issue in code generation compared to other AI applications, but it’s worth being aware of this possibility. More subtly, the AI might be biased toward solutions it saw more often, even if those aren’t the best for your case. Chapter 9 discusses bias and other ethical considerations.
并非所有开发者都能立即适应这种工作方式。编码本身就蕴含着某种乐趣和艺术性,而人工智能的介入可能会削弱这种乐趣和艺术性。此外,最初可能还会出现信任危机——“它真的做对了吗?”——而这只有通过良好的实践和时间的积累才能克服。采用人工智能的团队应该允许一段时间的适应,并鼓励经验和技巧的分享。随着时间的推移,就像任何工具一样,大多数团队最终会找到一种平衡点,既能重视人工智能的贡献,又能让人类的专业知识专注于他们最擅长的领域。
Not all developers are immediately comfortable with this style of work. Coding has a certain pleasure and artistry to it, and some may feel that is diminished by AI involvement. There can also be an initial lack of trust—“Did it really do this right?”—which only good practices and time can overcome. Teams adopting AI should allow a period of adjustment and encourage sharing of experiences and tips. Over time, as with any tool, most will find a balance where the AI’s contributions are valued and human expertise focuses on what humans do best.
以目标为导向的编程理念的转变,为软件开发带来了巨大的潜力,使其速度更快、更易于上手,并在许多方面更具乐趣。但要充分发挥这种潜力,就必须理解新的动态:如何有效地与人工智能沟通,如何验证其输出,以及如何负责任地将其集成到开发流程中。
The vibe shift toward programming with intent offers tremendous potential to make software development faster, more accessible, and in many ways more enjoyable. But realizing that potential means understanding the new dynamics: how to communicate with AI effectively, how to verify its output, and how to integrate it responsibly into your development process.
我通过使用这些工具和观察许多项目而形成的观点是,人工智能的最佳用途是……关键在于将创意“氛围”与扎实的工程规范相结合。鼓励人工智能带来的天马行空的想法和快速草稿——它们是我们掌握的全新超能力。但也要运用软件开发数十年来积累的智慧来引导它们:规划、测试以及理解你所构建的东西至关重要。
My perspective, forged from working with these tools and observing many projects, is that AI’s best use lies in combining the creative “vibe” with solid engineering hygiene. Encourage the wild ideas and rapid drafts that AI can offer—those are the new superpowers at our disposal. But channel them with the wisdom that software development has accumulated over decades: the importance of planning, testing, and understanding what you build.
当我们找到这种平衡点时,就能两全其美。我们既能开发出速度更快、更具创意的软件,又能拥有值得信赖、易于维护且发展壮大的软件。归根结底,这才是我们在人工智能时代提升自身技艺的方式:不是在追求感觉而非技术之间做出选择,而是要掌握两者之间的所有要素。
When we strike that balance, we get the best of both worlds. We get software that is built faster and potentially more imaginatively but also software that we trust, maintain, and grow with confidence. That, ultimately, is how we elevate our craft in the age of AI: not by choosing vibes over engineering, or vice versa, but by mastering the whole spectrum between.
接下来,第二章将探讨如何设计提示以及如何与人工智能协作。掌握了本章的基础概念后,您就可以开始探索这个新编程时代的实践应用了。这将为后续章节中的实践示例和更深入的提示技巧奠定基础。
Next, Chapter 2 explores the art of crafting prompts and collaborating with AI. With the foundational concepts from this chapter in mind, you’re ready to explore the practical side of this new programming era. This will set the stage for hands-on examples and deeper prompting techniques in subsequent chapters.
在Vibe编程中,提示就是新的源代码。
In vibe coding, prompts are the new source code.
你向人工智能传达意图的方式会直接影响它生成的代码质量。编写好的提示既是一门艺术,也是一门科学,通常被称为提示设计。本章将为您提供充分利用人工智能编码助手的技巧。我们将首先介绍提示语为何重要的基本原理,然后深入探讨一系列提示技巧,从简单到高级。通过学习如何编写有效的提示语以及如何迭代改进它们(图 2-1),您将能够更高效、更准确地与人工智能进行协同创作。
The way you communicate your intent to the AI has a direct impact on the quality of the code it generates. Writing a good prompt is both an art and a science, often called prompt engineering. This chapter will equip you with techniques to get the most out of your AI coding assistant. We’ll start with some fundamentals about why prompts matter and then delve into a toolbox of prompting techniques, from simple to advanced. By learning how to craft effective prompts and how to iteratively refine them (Figure 2-1), you’ll be able to cocreate with AI more efficiently and accurately.
如果说“氛围编码”是你和人工智能模型之间的对话,那么“提示工程”就是掌握人工智能的语言以获得最佳结果的技能。精心设计的提示能够决定代码建议是无关紧要还是存在缺陷,甚至能否提供完美的解决方案。掌握提示设计技巧意味着理解如何有效地引导人工智能,如何提供上下文信息,以及在第一次回答不尽如人意时如何与人工智能进行迭代优化。
If vibe coding is a conversation between you and an AI model, prompt engineering is the skill of speaking the AI’s language to get the best results. A well-crafted prompt can be the difference between an irrelevant or buggy code suggestion and a perfect solution. Mastering prompt engineering means understanding how to guide the AI effectively, how to provide context, and how to iterate with the AI when the first answer isn’t quite right.
当你使用人工智能进行编程时,本质上就是通过自然语言与人工智能进行交互。你提供的提示就像一种高级编程语言,人工智能解释器会将其翻译成实际的代码。正如编译器的输出质量取决于输入的源代码质量一样,人工智能的输出质量也取决于提示的质量。
When you program with an AI, you are essentially programming through the AI using natural language. The prompt you provide is like a high-level programming language that the AI interpreter then translates into actual code. Just as a compiler’s output is only as good as the source code fed to it, an AI’s output is only as good as the prompt.
为什么提示如此重要?LLM(法学硕士)虽然功能强大,但它们并非读心术士。它们只会对接收到的输入做出反应。含糊不清或措辞不当的提示会导致编写出无关或错误的代码,而清晰明确的提示则可能一次就能找到正确的解决方案。在传统编程中,你花费时间思考算法并编写代码;而在“感觉编程”中,你花费时间思考如何将你的需求传达给人工智能。这改变了“编写代码”的含义:你可能写的是一段文字而不是一个函数,但你仍然需要做到精确和合乎逻辑。
Why are prompts so important? LLMs, despite their sophistication, are not mind readers. They respond only to the input they’re given. Ambiguous or poorly worded prompts can lead to irrelevant or incorrect code, while a clear and specific prompt can yield a spot-on solution on the first try. In traditional coding, you spend time thinking about algorithms and writing code; in vibe coding, you spend time thinking about how to convey your requirements to the AI. It’s a shift in what “writing code” means: you might write a paragraph instead of a function, but you still need to be precise and logical.
把编写提示想象成给一个非常死板、拘泥于形式的初级开发人员编写文档或用户故事。这位开发人员会严格按照文档执行操作,他知识渊博,但除了见过的模式之外,缺乏常识。如果你的指令(提示)留有解读空间,人工智能可能会以你意想不到的方式填补这些空白。因此,学习如何与人工智能沟通,其重要性堪比过去学习编程语言的语法。
Think of writing prompts as being like writing documentation or user stories for a very literal and pedantic junior developer, one who will do exactly (and only) what the documentation says, and who has a lot of knowledge but no common sense beyond patterns they have seen. If your instructions (prompts) leave room for interpretation, the AI might fill the gaps in ways you didn’t intend. Thus, learning to communicate with the AI is as crucial as learning a programming language’s syntax used to be.
提示之所以至关重要,另一个原因是其可复现性和面向未来。如果你发现某个提示能够针对特定模式或任务可靠地生成优质代码,那么这个提示就成为宝贵的知识(几乎就像代码片段或模板一样)。你可以保存它,或在类似的场景中重复使用。在团队中,开发人员可以像分享编码最佳实践一样,彼此分享有效的提示模式。
Another reason prompts are crucial is reproducibility and future-proofing. If you discover a prompt that reliably generates good code for a certain pattern or task, that prompt becomes a valuable piece of knowledge (almost like a snippet or template). You might save it or reuse it in similar contexts. In teams, developers might share effective prompt patterns with each other, similar to how they share coding best practices.
最后,随着模型的不断完善和集成,它们或许能够实现更复杂的交互。善于引导用户将使您能够快速掌握这些新功能。例如,一些高级系统允许您附加详细的说明或提供完整的参考文档作为模型上下文的一部分。了解如何组织这些输入是充分利用这些功能的关键。
Finally, as models get better and more integrated, they may allow more complex interactions. Being good at prompting will let you harness new capabilities quickly. For instance, some advanced systems allow you to attach extensive instructions or provide entire reference documents as part of the context for the model. Knowing how to structure that input is key to leveraging such power.
因此,请将提示写作视为一项新的必备技能。从很多方面来看,提示写作与编程类似。主要区别在于,你用一种语言(例如英语)写作,然后人工智能会将其转换为代码。但你仍然需要在描述中做到清晰、逻辑严密,并预见可能出现的特殊情况。
So treat prompt writing as a new essential skill. In many ways, prompting is programming. The main difference is you’re writing in a language (like English) that the AI then converts into code. But you still have to be clear, logical, and anticipate edge cases in your description.
提示的黄金法则之一(我将在第 3 章中更详细地阐述)是具体、清楚地表达你想要什么。与人类合作者不同,人工智能无法真正理解你提供的文字之外的目标。一个常见的错误是给人工智能一个非常笼统的指令,比如“创建一个网站”,然后就期待它能创造奇迹。人工智能更擅长处理具体的细节。
One of the golden rules of prompting (which I’ll lay out more fully in Chapter 3) is to be specific and clear about what you want. Unlike a human collaborator, an AI doesn’t truly understand your goal beyond the words you provide. A common mistake is giving the AI a very high-level prompt like “Make a website” and expecting magic. The AI works better with concrete details.
始终假设它对你的项目一无所知,只知道你提供的信息。务必包含相关细节,例如编程语言、框架和库,以及相关的具体函数或代码片段。如果出现错误,请提供准确的错误信息并描述代码的预期功能。任何含糊不清或留有解释空间的描述都可能导致意想不到的结果。
Always assume it knows nothing about your project beyond what you provide. Include relevant details such as the programming language, framework, and libraries, as well as the specific function or snippet in question. If there’s an error, provide the exact error message and describe what the code is supposed to do. Any vagueness or room for interpretation can lead to unintended outputs.
例如,与其说“编写一个排序函数”,不如说:
For example, instead of “Write a sorting function,” you could say:
编写一个 Python 函数 `sort_by_lastname(customers)`,该函数接收一个客户记录列表(每条记录包含 `first_name` 和 `last_name` 字段),并返回一个按 `last_name` 字母顺序排序的列表。函数需包含简短的文档字符串,并处理缺失的 `last_name` 字段,将其视为空字符串。
Write a Python function sort_by_lastname(customers) that takes a list of customer records (each with a first_name and last_name field) and returns a list sorted by last_name alphabetically. Include a brief docstring and handle the case of missing last names by treating them as empty strings.
这个提示明确规定了语言(Python)、函数名称和用途、输入结构、排序键、附加要求(文档字符串)以及一个特殊情况。它很可能会生成完全符合你需求或非常接近的结果。本质上,要像编写规范一样思考:你对任务的描述越精确,AI 需要做的猜测就越少,你需要修改的次数也就越少。
This prompt sets clear expectations about the language (Python), the function name and purpose, the input structure, the sort key, additional requirements (docstring), and an edge case. It’s likely to produce exactly what you need or very close to it. Essentially, think like a spec writer: the more precisely you specify the task, the less guesswork the AI has to do and the fewer revisions you’ll need.
Strategies for specificity include:
如果你想要一个解决方案在 JavaScript 中,要明确说明:“编写一个 JavaScript 函数……”,而不是仅仅说“编写一个函数……”。如果想要针对特定的框架或版本,也要说明(例如“使用 React Hooks……”或“在 Python 3 中……”)。
If you want a solution in JavaScript, say so: “Write a JavaScript function...” versus just “Write a function...” If you want it for a specific framework or version, include that (“Using React Hooks...” or “in Python 3...”).
您只需要一个函数?一个完整的文件或模块?需要包含测试吗?例如,“仅提供函数实现”和“提供完整的可运行脚本”可能会得到不同的结果。
Do you want just a single function? A full file or module? Tests included? For example, “Provide only the function implementation” and “Provide a complete runnable script” can yield different responses.
在登录示例中,我们指定了密码长度和尝试次数限制。考虑一下各种极端情况或限制条件,并将它们写在提示中。如果需要对代码进行性能优化或使用某种算法,请明确说明:“使用 O(n) 时间和 O(1) 空间”或“使用二分查找方法”。
In the login example, we specified password length and attempt limit. Think of edge cases or constraints and put them in the prompt. If you need the code to be optimized for performance or use a certain algorithm, say so: “using O(n) time and O(1) space” or “using a binary search approach.”
Don’t use words like it without a clear antecedent. Instead of “Process it and return the result,” say, “Process the array and return the resulting array.”
如果你想要要让 AI 只输出代码,或者只输出带有注释或解释的代码,您可以指示:“只提供代码,不提供解释”或“提供代码以及每个步骤的简要注释”。
If you want the AI to output just code or code with comments or an explanation, you can instruct that: “Give only the code, no explanation” or “Provide code and a brief comment for each step.”
清晰的提示有助于人工智能成功运行。如果您发现人工智能的答案经常需要大量修正,请检查您的提示是否不够明确。
A clear prompt sets the AI up for success. If you find the AI’s answers often need a lot of correction, examine whether your prompts might be underspecified.
以下是不应该做的事情:
Here’s what not to do:
冗长的提示信息,尤其是包含无关信息的部分,可能会让模型感到困惑,或者导致它关注错误的内容。描述要简洁完整。例如,在编程语境中,通常不需要以“你是一位世界级的程序员……”开头(虽然有些人会在 ChatGPT 的一般使用中这样做,但对于编程任务来说,这通常是不必要的,而且可能会增加干扰)。
Long-winded prompts that include irrelevant info can confuse the model or cause it to focus on the wrong thing. Be concise but complete in your description. For instance, you usually don’t need to preface with “You are a world-class programmer...” in a coding context (some people do that in general ChatGPT usage, but for coding tasks, it’s often unnecessary and could add noise).
如果某些方面很重要(例如线程安全、特殊字符处理等),请务必提及。如果没有提及,则假定 AI 可能无法处理。
If something is important (like thread safety, handling of special characters, etc.), mention it. If it’s not mentioned, assume the AI might not handle it.
例如,如果你说“编写一些代码来分析数据”,人工智能可能会猜测你想要进行哪种分析。相反,你应该明确指出:
For example, saying, “Write some code to analyze data” might cause the AI to guess what analysis you want. Instead, specify:
计算一组数字的平均值和标准差。
Calculate the average and standard deviation of a list of numbers.
总之,务必准确表达你的意思。人工智能越了解你的真实需求,就能提供越好的服务。如果你发现自己需要多次纠正人工智能,不妨问问自己:我最初的提示是否更清晰一些?
In summary, say exactly what you mean. The more the AI “knows” about what you truly want, the better it can deliver. If you find yourself having to correct the AI multiple times, ask: could my initial prompt have been clearer?
即使有明确的提示,你也不总是第一次就能获得完美答案。把与人工智能的交互想象成一次对话或一个迭代开发过程。这就是我在第一章中提到的反馈回路。
Even with clear prompts, you won’t always get the perfect answer on the first try. Think of interacting with the AI as a conversation or an iterative development process. This is the feedback loop I touched on in Chapter 1.
当人工智能给出代码时,请像审阅人类编写的代码一样,对其进行严格审查。它是否符合要求?如果不符合,请找出缺失或错误之处。然后提供反馈或更清晰的提示。在对话式人工智能中,只需继续对话即可;在编辑器中,则可以编写新的评论供人工智能回复。
When the AI gives you code, review it critically, just as you would code written by a human. Does it meet the requirements? If not, identify what’s missing or wrong. Then provide feedback or a refined prompt. This can be done in a conversational AI by simply continuing the dialogue, or in an editor by writing another comment for the AI to respond to.
通过向人工智能提供反馈,你可以引导它更接近你想要的结果。 从某种意义上说,你是在针对特定问题进行即时训练。高级提示设计就像图 2-2中的循环:提示 → AI 输出 → 审核 → 优化提示 → AI 输出 →……直到满意为止。每次迭代的改动幅度越小越好;如果对提示进行过多修改,可能会丢失之前输出中的一些有效信息。
By providing feedback to the AI, you steer it closer to your desired outcome. In a sense, you are training it on the fly for your specific problem. Advanced prompt engineering is like the loop in Figure 2-2: Prompt → AI output → Review → Refine prompt → AI output →...until satisfied. Keeping each iteration’s changes small is useful; if you overhaul the prompt too much, you may lose some good parts of the previous output.
例如,您可以提示:
For example, you might prompt:
编写一个函数,该函数接受一个整数列表并返回它们的和。
Write a function that takes a list of integers and returns their sum.
AI随后返回一个函数,但它的代码假定列表非空,无法很好地处理空列表。你可以这样回复:
The AI then returns a function, but its code assumes a non-empty list and doesn’t handle an empty list well. You could then reply:
看起来不错。不过,请修改一下,如果列表为空,则返回 0。
That looks good. However, please modify it to return 0 if the list is empty.
然后,人工智能会相应地更新函数。这样一来,你无需从头开始编写指令;你只需告诉人工智能进行调整即可。人工智能已经掌握了之前代码的上下文信息。
The AI would then update the function accordingly. In this way, you didn’t have to prompt from scratch; you just told the AI to make an adjustment. The AI already had the context of the previous code it gave.
如果你使用的是内联助手,改进可能就像编辑代码,并添加类似这样的注释# TODO: handle empty list,然后看看人工智能是否会建议修复方案。
If you’re using an inline assistant, refinement might look like editing the code and perhaps writing a comment like # TODO: handle empty list and then seeing if the AI suggests a fix for that.
另一种改进方法是,如果第一次输出不正确,则提供更多信息进行重新提示。假设您说“对名称列表进行排序”,它给出了区分大小写的排序代码,但您想要不区分大小写的排序。您可以重新表述:
Another refinement approach is reprompting with more info if the first output wasn’t right. Suppose you said, “Sort a list of names,” and it gave code sorting case-sensitively but you wanted case-insensitive. You could rephrase:
对名称列表进行不区分大小写的排序。
Sort a list of names case-insensitively.
或者甚至:
Or even:
之前的代码区分大小写排序。请修改为不区分大小写。
The previous code sorts case-sensitively. Modify it to be case-insensitive.
在调试过程中,更多信息对于复杂的逻辑错误(没有明显的错误信息,但输出结果错误),您可以引导 AI 逐步执行代码。例如:
In debugging, for more complex logic bugs (where no obvious error message is thrown but the output is wrong), you can prompt the AI to walk through the code’s execution. For instance:
逐行检查这个函数,并跟踪每一步的总数值。它没有正确累加——逻辑哪里出错了?
Walk through this function line by line and track the value of total at each step. It’s not accumulating correctly—where does the logic go wrong?
这是一个“橡皮鸭”调试提示的示例:你是本质上,这是要求人工智能模拟人类使用打印语句或调试器进行的调试过程。这类提示通常会揭示一些细微的问题,例如变量未重置或条件逻辑错误,因为人工智能会详细说明每一步的状态。如果您怀疑代码的某个部分存在问题,可以放大查看:
This is an example of a “rubber duck” debugging prompt: you’re essentially asking the AI to simulate the debugging process a human might do with prints or a debugger. Such prompts often reveal subtle issues like variables not resetting or incorrect conditional logic, because the AI will spell out the state at each step. If you suspect a certain part of the code, you can zoom in:
请解释一下这里的筛选调用做了什么,以及它是否排除了比应该排除的更多的项目。
Explain what the filter call is doing here and if it might be excluding more items than it should.
让人工智能扮演解释者的角色,可能会在解释过程中发现错误。
Engaging the AI in an explanatory role can surface the bug in the process of explanation.
解释完毕后,直接提出你的需求往往很有效:
After the explanation, it’s often effective to directly ask for what you need:
造成这个问题的原因可能是什么?我该如何解决?
What might be causing this issue, and how can I fix it?
这样可以引导人工智能进行诊断并提出解决方案。如果人工智能的第一个答案不够清晰或只有部分帮助,请随时提出后续问题:
This invites the AI to both diagnose and propose a solution. If the AI’s first answer is unclear or partially helpful, don’t hesitate to ask a follow-up question:
这个解释很有道理。你能告诉我如何修改代码吗?请提供修改后的代码。
That explanation makes sense. Can you show me how to fix the code? Please provide the corrected code.
在聊天环境下,AI 会保留对话历史记录,因此可以直接输出修改后的代码。如果您使用的是 VSCode 中的 Copilot 或 Cursor 等内联工具(没有聊天功能),则可以在代码上方添加注释:
In a chat setting, the AI has the conversation history, so it can directly output the modified code. If you’re using an inline tool like Copilot in VSCode or Cursor without a chat, you might instead write a comment above the code:
// 错误:返回 NaN,修复此函数并查看其自动补全功能是否正常。
// BUG: returns NaN, fix this function and see how it autocompletes
不过总的来说,互动聊天能提供更详尽的解释。
In general, though, the interactive chat yields more thorough explanations.
另一个后续模式:如果人工智能给出了解决方案,但你不明白为什么,请提问:
Another follow-up pattern: if the AI gives a fix but you don’t understand why, ask:
你能解释一下为什么这个改变能解决问题吗?
Can you explain why that change solves the problem?
这样,你就能吸取教训,为下次做好准备,并再次确认人工智能的推理是否合理。
This way, you learn for next time, and you double-check that the AI’s reasoning is sound.
法学硕士课程注重举例和纠正。如果你指出哪里出了问题或举个简单的例子,人工智能就能将其融入到系统中:
LLMs thrive on examples and corrections. If you point out what’s wrong or give a quick example, the AI can incorporate it:
如果输入为空字符串([]),则应返回 0,但现在却报错。
If input is [], it should return 0, but now it errors.
这种反复沟通的过程很正常。事实上,试图一次性把所有细节都塞进一个问题里,可能不如反复讨论几次有效。要善加利用这一点。
This iterative process is normal. In fact, trying to cram every detail into one prompt might be less effective than a couple of back-and-forth turns. Use that to your advantage.
反馈时要耐心且具体。不要只说“不,那是错的”,而是要具体说明哪里错了或者需要做什么:
Be patient and specific in your feedback. Instead of saying, “No, that’s wrong,” say what’s wrong or what’s needed:
这段代码对负数的处理不正确。在计算总和时,应该将负数视为 0。
This code doesn’t handle negative numbers correctly. It should treat them as 0 in the sum.
此外,如果人工智能偏离了轨道,你可以引导它回到正轨:有时重置或重新措辞比试图挽救一个完全错误的尝试要容易得多。运用你的判断力。如果人工智能的输出表明它完全误解了你的指令,请从头开始重新解释你的提示。
Also, if the AI goes off track, you can steer it back: sometimes resetting or rephrasing is easier than trying to salvage a very incorrect attempt. Use your judgment. If the AI output shows that it is completely misunderstanding you, clarify your prompt from scratch.
随着你的不断改进,你还会了解人工智能是如何解读你的提示的。这可以指导你如何编写未来的提示。你可能会意识到,“哦,原来‘登录系统’指的是整个用户界面。下次我只需指定后端即可。”
As you refine, you’ll also learn how the AI interpreted your prompt. This can inform how you write future prompts. You might realize, “Oh, it took ‘login system’ to mean an entire UI. Next time I’ll specify backend only.”
把它想象成调试代码:如果人工智能的输出有误,“错误”可能出在你的提示信息上,而不是人工智能的处理过程。就像你会检查并修复代码的错误结果一样,当人工智能产生意外或错误的输出时,你也应该改进你的提示信息。你和人工智能之间的对话就像一次调试过程,每一次交流都能帮助你找到并解决问题。
Think of it like debugging code: if the AI output is wrong, the “bug” might be in your prompt, not in the AI’s processing. Just as you’d examine and fix your code when it produces incorrect results, you should refine your prompts when the AI generates unexpected or incorrect output. The conversation between you and the AI is like a debugging session where each exchange helps you pinpoint and fix the issue.
想象你有一个简单的 Node.js 函数,旨在将用户对象列表按用户 ID 转换为查找映射。但是,它抛出了一个错误。以下是出错的代码:
Imagine you have a simple Node.js function meant to convert a list of user objects to a lookup map by user ID. However, it’s throwing an error. Here’s the buggy code:
// Buggy function: converts array of users to a map by IDfunctionmapUsersById(users){constuserMap={};for(leti=0;i<=users.length;i++){// Note: using <= will go out of bounds on the last iterationconstuser=users[i];userMap[user.id]=user;}returnuserMap;}// Example usage:constresult=mapUsersById([{id:1,name:"Alice"}]);
// Buggy function: converts array of users to a map by IDfunctionmapUsersById(users){constuserMap={};for(leti=0;i<=users.length;i++){// Note: using <= will go out of bounds on the last iterationconstuser=users[i];userMap[user.id]=user;}returnuserMap;}// Example usage:constresult=mapUsersById([{id:1,name:"Alice"}]);
这段代码的目的是遍历用户数组并构建一个以用户 ID 为键的对象。然而,这里存在一个错误:循环使用了 `<user>`i <= users.length而不是 `<user>` i < users.length。这将导致users[i]在最后一次迭代时 `<user>` 为 `undefined`,很可能导致运行时错误(例如,尝试访问 `<user>` 的 `ID` 属性undefined)。让我们看看 AI 助手会如何响应关于此问题的两种不同提示(参见图 2-3)。
This code is supposed to iterate through the user’s array and build an object where keys are user IDs. However, there is a bug: the loop uses i <= users.length instead of i < users.length. This will cause users[i] to be undefined on the last iteration, likely leading to a runtime error (like attempting to access the property ID of undefined). Let’s see how an AI assistant might respond to two different prompts about this issue (see Figure 2-3).
Here’s an example of a poor prompt:
为什么我的 mapUsersById 函数不起作用?
Why isn’t my mapUsersById function working?
AI对糟糕提示的反应(模拟):
AI’s response to the poor prompt (simulated):
没有更多信息很难判断具体原因。您确定调用该函数时传入的是正确的用户数组吗?问题可能出在 `users` 数组为空或不是数组,导致循环无法正常执行。也可能是设置 `userMap` 属性时出错。请确保每个用户都有一个 `id` 属性。如果 `users` 为 `undefined` 或 `null`,也会导致循环无法正常工作。
It’s hard to say without more information. Are you sure the function is being called with a proper array of users? Perhaps the issue is that users is empty or not an array, causing the loop not to execute properly. It could also be that there’s an error when setting the property on userMap. Make sure that each user has an id property. If users is undefined or null, that would also cause it to not work.
这个答案相当笼统。提示信息除了函数名之外没有提供任何细节,所以人工智能只能猜测一些通用原因(例如“数组可能为空或根本不是数组”、“确保每个用户都有一个ID”)。它并没有找到真正的错误所在。
This answer is quite vague. The prompt gave no details except the function name, so the AI is guessing at generic causes (“Maybe the array is empty or not an array,” “Make sure each user has an ID”). It did not identify the actual bug.
当问题描述不够具体时,就会得到这样的回复——模型只能复述一些常见的调试技巧。如果你是一名开发者,这没什么帮助,因为它没有解决真正的问题。提示缺乏上下文和具体信息,导致得到的答案过于笼统:本质上,这相当于人工智能版的“你试过重启吗?”。这与社区的建议一致,即模糊的提示会导致无关或通用的答案。
This is the kind of response you get when the question is underspecified—the model can only regurgitate common debugging tips. If you’re a developer, this isn’t very helpful because it doesn’t address the real mistake. The lack of context and specificity in the prompt yields a generic answer: essentially, the AI equivalent of “Have you tried turning it off and on again?” This aligns with the community advice that vague prompts lead to irrelevant or generic answers.
我有一个 JavaScript 函数
mapUsersById,它应该将一个用户对象数组转换为map (object)以用户 ID 为键的数组。但是,当我运行它时,它会抛出一个错误。例如,当我传递 `user_id` 参数时[ {id: 1, name: "Alice"} ],我得到的结果是`[user_id]`。TypeError: Cannot read property 'id' of undefined以下是函数代码:function mapUsersById(users) { const userMap = {}; for (let i = 0; i <= users.length; i++) { const user = users[i]; userMap[user.id] = user; } 返回用户映射; }它应该会返回结果
{ "1": {id: 1, name: "Alice"} }。这是什么bug?我该如何修复?
I have a JavaScript function
mapUsersByIdthat should convert an array of user objects into amap (object)keyed by user ID. However, it throws an error when I run it. For example, when I pass[ {id: 1, name: "Alice"} ], I getTypeError: Cannot read property 'id' of undefined. Here is the function code:function mapUsersById(users) { const userMap = {}; for (let i = 0; i <= users.length; i++) { const user = users[i]; userMap[user.id] = user; } return userMap; }It should return
{ "1": {id: 1, name: "Alice"} }. What is the bug and how can I fix it?
人工智能对改进后的提示的响应(模拟):
The AI’s response to the improved prompt (simulated):
错误“无法读取
'id'未定义对象的属性”表明,在某个时刻,`user` 为 `undefined`,然后您尝试访问 `user.id`。查看您的循环,问题出在循环边界上。您使用了 `if` 语句i <= users.length。如果users.length`user`为 `undefined`1(对于数组中的一个 `user`),循环会以 ` undefined`i = 0和 `undefined`运行i = 1。当`iuser` 为`undefined` 时1,users[1]`user` 为 `undefined`(因为数组中唯一的索引是 0)。因此,`user` 在该次迭代中变为 `undefined`,并user.id抛出 `undefined`TypeError。解决方法是将循环条件更改为 `i < users.lengthif` 语句,使 `undefined`i从0`undefined`users.length-1变为 `undefined`。例如:for (let i = 0; i < users.length; i++) { const user = users[i]; userMap[user.id] = user; }这样一来,循环
i将只0针对第一个(也是唯一一个)元素,然后循环停止。做出此更改后,您的函数将不再遇到未定义的用户,并且应该能够按预期工作,返回{"1": {id: 1, name: "Alice"}}给定输入的值。
The error Cannot read property
'id'of undefined suggests that at some point, user is undefined, and then you try to access user.id. Looking at your loop, the issue is with the loop bounds. You are usingi <= users.length. Ifusers.lengthis1(for one user in the array), the loop runs withi = 0andi = 1. Wheniis1,users[1]is undefined (since the only index in the array is 0). Thus user becomes undefined on that iteration, anduser.idthrows aTypeError. The fix is to change the loop condition toi < users.lengthso thatigoes from0tousers.length-1. For example:for (let i = 0; i < users.length; i++) { const user = users[i]; userMap[user.id] = user; }This way,
iwill be0for the first (and only) element, and then the loop stops. With that change, your function will no longer hit an undefined user and should work as expected, returning{"1": {id: 1, name: "Alice"}}for the given input.
这个回复直接指出了错误所在(<=在循环中使用 `if`),并解释了为什么它会导致 `user` 未定义。然后,它提供了正确的代码解决方案(` i < users.lengthif`),并确认了预期结果。改进后的提示之所以成功,是因为它遵循了我们的原则:它明确指出了编程语言(JavaScript),描述了函数的用途,包含了准确的错误信息和示例输入,甚至还提供了相关的代码片段。
This response directly pinpoints the bug (using <= in the loop) and explains why it causes the user to be undefined. It then provides the correct code solution (i < users.length) and confirms the expected outcome. The improved prompt succeeded because it followed our principles: it specified the language (JavaScript), described the function’s purpose, included the exact error message and a sample input, and even provided the code snippet in question.
注意人工智能是如何利用错误信息作为线索,将注意力集中在循环边界上的——有针对性的提示使人工智能能够真正解决问题,有效地模拟了人类调试人员的思考方式:“未定义值可能来自哪里?很可能来自循环索引。” 这就是详细提示带来的益处的具体体现。
Notice how the AI used the error message as a clue to focus on the loop bounds—a targeted prompt enabled the AI to engage in true problem solving, effectively simulating how a human debugger would think: “Where could undefined come from? Likely from the loop indexing.” This is a concrete demonstration of the benefit of detailed prompts.
现在我们来深入探讨一些具体技巧。这可以极大地提升你的提示技巧。这些就像模式或配方,当简单的指令不足以满足需求,或者你想以某种特定方式引导人工智能时,你可以使用它们。
Now let’s get into specific techniques that can supercharge your prompting skills. These are like patterns or recipes you can use when a straightforward instruction isn’t enough or when you want to guide the AI in a certain way.
掌握这些技巧,你就能应对各种情况:用简单的英语指导人工智能,提供示例,让它解释或组织输出内容,或者设置不同的思维模式或角色。所有这些都能帮助你引导人工智能生成你真正需要的内容。
By mastering these techniques, you can handle an array of situations: instructing the AI in plain English, giving it examples, making it explain or structure its output, or setting it into different mindsets or roles. All of these help you guide the AI to produce exactly what you need.
提示技巧并非相互排斥;为了取得最佳效果,尤其是在处理复杂任务时,通常会同时使用几种技巧。
Prompting techniques are not mutually exclusive; you will often use several together for best results, especially on complex tasks.
使用这些技巧时,要根据模特调整你的语气。许多模型对礼貌或中性的指令反应良好。您无需使用古旧或过于正式的语言。直接但礼貌的表达往往有效,例如:“请做X”或“我们来做Y”。例如,在使用链式思维(CoT)提示时,常用的短语是“我们一步一步地思考”。像GPT-4这样的模型会将此识别为展示推理过程的提示。
When you use these techniques, adapt your tone to the model. Many models respond well to polite or neutral instructions. You don’t need to use archaic or overly formal language. Direct but polite often works: “Please do X” or “Let’s do Y.” For example, with chain-of-thought (CoT) prompting, a popular phrase is “Let’s think step-by-step.” Models like GPT-4 recognize this as a cue to show reasoning.
零次提示是只是问问该模型要求在不提供任何示例或额外指导的情况下完成某项任务。本质上,该模型是从“零”示例出发解决问题。
Zero-shot prompting is simply asking the model to do something without providing any examples or additional guidance beyond the instruction. Essentially, the model is solving the task from “zero” examples.
何时使用:这是最常见的情况:只需用简洁明了的语言提出你的需求即可。如果任务是标准的,并且提示清晰,通常这样就足够了。
When to use: This is the most common scenario: you just ask for what you want in plain language. If the task is standard and the prompt is clear, this is often sufficient.
例子:
Example:
编写一个Python函数,检查一个数是否为质数。
Write a Python function that checks if a number is prime.
这是零概率事件。人工智能很可能会使用循环或试除法来生成质数检验函数。
This is zero shot. The AI will likely produce a prime-checking function using a loop or trial division.
优点:速度快,并且依赖于模型已学习到的知识。现代模型在很多编程任务中,尤其是在常见任务(例如素数检查、排序或字符串操作)方面,都能出人意料地出色地完成零样本响应。
Pros: It’s quick and relies on the model’s learned knowledge. Modern models are surprisingly good at zero-shot responses for many programming tasks, especially if they’re common (like prime checking, sorting, or string manipulation).
缺点:如果任务不寻常或输出格式有特殊性,零次尝试可能无法在第一次尝试时产生完全符合您需求的结果,因为模型可能有多种解释方式。
Cons: If the task is unusual or output format is specific, zero shot might yield a result that doesn’t quite match what you need on the first try, because the model might have multiple ways to interpret it.
通常来说,对于简单的拍摄,最好先尝试零度拍摄。如果效果不理想,再考虑精细拍摄或其他拍摄技巧。
Usually, it’s a good idea to try zero shot first for simple things. If the result is off, you may then shift to refining or other techniques.
一次性提示意味着你提供提示中只需提供一个你想要的示例(输入和期望的输出);少样本提示是指在要求模型对新输入执行任务之前,提供几个示例(通常是两到五个)。
One-shot prompting means you provide exactly one example of what you want (input and desired output) as part of the prompt; few-shot prompting means providing a few examples (typically two to five) before asking the model to perform the task on a new input.
这就像向模型展示:“这是我解决一个实例的方法。现在你用类似的方法解决下一个实例。”
This is like showing the model, “Here’s how I solve one instance. Now you do the next one similarly.”
何时使用:当模特可能不太清楚您需要的格式或风格,或者任务比较特殊时,这种提示方式非常有用。通过提供示例,您可以减少歧义。
When to use: This type of prompting is useful when the model might not know exactly the format or style you need or when the task is a bit unusual. By giving examples, you reduce ambiguity.
示例(仅举一例):假设您使用的语言或某种风格是模型可能不太熟悉的。假设您想要特定格式的伪代码。您的提示可能是:
Example (one shot): Suppose you’re using a language or a certain style that the model might not have seen as much. Let’s say you want pseudocode in a specific format. Your prompt might be:
将以下英文指令转换为类似 Python 的伪代码。
Convert the following English instructions to Python-like pseudocode.
示例指令:“计算 n 的阶乘”:
Example instruction: “Calculate the factorial of n”:
伪代码示例:
函数 factorial(n):
如果 n <= 1:
返回 1
别的:
返回 n * factorial(n-1)
指令:“找出列表中的最大数字”
伪代码:Example pseudocode:
function factorial(n):
if n <= 1:
return 1
else:
return n * factorial(n-1)
Instruction: "Find the largest number in a list"
Pseudocode:
您提供了一个例子(阶乘)以及您想要的格式。现在,该模型更有可能以类似的格式(包含函数、必要的 if/else 语句或循环逻辑)生成“最大数字”指令的伪代码。
You’ve provided one example (factorial) and the format you want. Now the model is more likely to produce pseudocode for the “largest number” instruction in a similar format (with a function, with if/else or loop logic as needed).
举例(少量示例):假设你想让AI使用某个特定的算法。你可以给它提供一个该算法实际运行的小例子作为提示。或者,如果任务有多个正确答案,但你更倾向于某个特定答案,那么一个示例可以引导它选择那个答案。
Example (few shot): Let’s say you want the AI to use a specific algorithm. You might give it a smaller example of that algorithm in action as a hint. Or if the task has multiple correct answers but you prefer a certain one, an example can push it toward that.
少量提示对于格式化非常有效;例如:
Few-shot prompting is powerful for formatting; for instance:
将以下英文语句转换为 SQL 查询。\N1.“获取所有 2020 年之后入职的员工”→ Select * From Employees Where Hire_Date > '2020-01-01';\N2.“列出上个月购买过商品的客户姓名”→ Select Name From Customers Join Purchases On ... Where Purchase_Date > ...;\N3.“统计缺货商品数量”→
Convert The Following English Statements To SQL Queries.\N1."Get All Employees Hired After 2020” → Select * From Employees Where Hire_Date > ’2020-01-01’;\N2. “List Customer Names Who Made A Purchase In The Last Month” → Select Name From Customers Join Purchases On ... Where Purchase_Date > ...;\N3. “Count Of Products That Are Out Of Stock” →
在这里,一旦你提供两个英语到 SQL 的示例,人工智能很可能就能遵循同样的模式正确回答第三个查询。这种小样本方法也适用于编程:先用一个小样本向人工智能展示你想要的风格,然后再要求它提供更多。这就像在你的提示中给它提供了一个小型训练数据集。
Here, once you give two examples of English-to-SQL, the AI is likely to answer the third query correctly by following the pattern. Few-shot examples can be applied to coding too: show the AI the style you want in a small sample and then ask for more. It’s like giving it a minitraining dataset within your prompt.
优点:可以实现特定风格的输出。这种技术还有助于模型处理需要遵循某种模式或重复应用某个概念的任务。
Pros: You can achieve outputs in very specific styles. This technique also helps the model handle tasks that involve following a pattern or applying a concept repetitively.
上下文窗口一词指的是最大窗口。语言模型在单次交互中能够处理的文本量(以词元为单位)是有限的,包括输入提示和生成的响应。这代表了当前人工智能模型的一个局限性——一旦达到这个阈值,模型就无法处理更多信息。在编写提示时,你包含的所有内容(说明、示例、数据以及响应所需的空间)都必须符合这个固定的容量限制。
The term context window refers to the maximum amount of text (measured in tokens) that a language model can process in a single interaction, including both the input prompt and the generated response. This represents a limitation of current AI models—once you reach this threshold, the model cannot process additional information. When you’re crafting prompts, everything you include (instructions, examples, data, and the space needed for the response) must fit within this fixed capacity.
缺点:尤其是少样本提示时,提示信息会更长(从而占用上下文窗口)。对于非常大/复杂的示例,它可能会“消耗”模型的大量容量。但通常一两个小示例就足够了。
Cons: Few-shot prompting in particular makes the prompt longer (which uses up context window). For very large/complex examples, it might “eat” a lot of the model’s capacity. But usually a small example or two is fine.
提示:如果您希望模型严格遵循某种输出结构,给出示例几乎可以保证它与该结构匹配,而不是提供您必须解析的自由格式回复。
Tip: If you want the model to strictly adhere to a certain output structure, giving an example can nearly guarantee it matches that structure rather than offering a free-form reply that you have to parse.
思维链(CoT) 提示是指要求模型逐步思考或展示其推理过程,然后再给出最终答案。换句话说,你要鼓励模型来分解问题。
Chain-of-thought (CoT) prompting involves asking the model to think step-by-step or show its reasoning before giving the final answer. In other words, you encourage the model to break down the problem.
何时使用:此功能适用于涉及推理和多步骤计算的复杂问题,或者当您怀疑模型如果直接给出答案可能会出错时。如果您希望输出结果包含解释,此功能也很有用。
When to use: This is useful for complex problems that involve reasoning and multistep computations, or when you suspect the model might make a mistake if it jumps straight to the answer. It’s also useful if you want an explanation in the output.
组合数学研究的是根据特定规则或约束条件对对象进行计数、排列和选择。常见问题包括排列(顺序重要的排列)、组合(顺序无关的选择)以及其他计数原理的计算。关键符号包括“n选k”(记作C(n,k)或nCk),它表示从n个元素中选择k个元素的方法数,计算公式为n!/(k!(nk)!)。这些计算经常出现在概率论、统计学和离散数学的应用中。
Combinatorial math deals with counting, arranging, and selecting objects according to specific rules or constraints. Common problems include calculating permutations (arrangements where order matters), combinations (selections where order does not matter), and other counting principles. Key notation includes “n choose k” (written as C(n,k) or nCk), which represents the number of ways to choose k items from n total items, calculated using the formula n!/(k!(n-k)!). These calculations frequently appear in probability, statistics, and discrete mathematics applications.
例如:与其直接问一个组合数学问题,比如“12选4等于多少?”并得到答案,你不如这样说:
Example: Instead of just asking a combinatorial math problem like “What is 12 choose 4?” and getting an answer, you might say:
逐步解答“选12个4”的问题。
Solve 12 choose 4 step-by-step.
该模型可能会概述:
The model might then outline:
12 选 4 = 12!/(4!*8!) = ... = 495
12 choose 4 = 12!/(4!*8!) = ... = 495
在编程中,CoT 可以用于处理棘手的算法任务。您可以尝试以下提示:
In coding, CoT can be useful for tricky algorithmic tasks. You might try the following prompt:
请一步一步地解释如何合并两个已排序的列表,并提供 Python 代码。
Explain step-by-step how to merge two sorted lists, then provide the Python code.
该模型首先会概述类似以下内容:
The model would first outline something like:
我们将使用两个指针,分别指向两个列表的头部,比较元素,将较小的元素添加到结果列表中,然后移动该指针,依此类推……
We will use two pointers starting at the heads of each list, compare the elements, append the smaller to a result list, and move that pointer, and so on…
然后它可能会给出代码。这确保了它在编写代码之前已经正确地构建了解决方案。
Then it might give the code. This ensures it has structured the solution correctly before coding.
另一个用途是调试或理解输出:
Another use is debugging or understanding output:
请逐步解释判断数字 19 是否为质数的逻辑,并给出结果。
Walk through the logic to determine if the number 19 is prime, then give the result.
该模型可能会列出所有素数除法,然后得出结论:
The model might list divisions by primes, then conclude:
19是质数。
19 is prime.
优点:提高需要推理任务的正确率。有研究表明,引导模型“大声思考”可以提高其在数学和逻辑任务上的表现。它还能让你深入了解模型的运行过程,这可能会对你有所启发,或者帮助你更加信任答案。
Pros: Improves correctness on tasks requiring reasoning. There’s research evidence that prompting the model to “think out loud” can lead to better results on math and logic tasks. It also gives you insight into the model’s process, which can be instructive or help you trust the answer more.
缺点:输出代码较长(这可能并非最终代码所需的格式)。此外,某些界面(例如典型的代码补全)并未设置为将推理过程与代码分开显示。这种技术在问答或聊天场景中更为常见。不过,您可以指示模型将推理过程作为注释添加到代码中,这是一种获得完整注释代码的巧妙方法。
Cons: The output is longer (which might not be what you want in final code). Also, some interfaces (like typical code completions) aren’t set up to show reasoning separate from code. This technique is more common in Q&A or chat scenarios. However, you can instruct the model to include the reasoning as comments in the code, which is a neat way to get thoroughly commented code.
角色提示是指你要求人工智能扮演某种身份或角色,这可能会影响它的响应方式。
Role prompting means you ask the AI to assume a certain identity or role that might influence how it responds.
何时使用:当您想要影响答案的风格或细节,或者想要获得某种特定视角时,此功能非常有用。例如,扮演“专家”角色的AI可能会给出更高级的解决方案或更详细的解释,而扮演“新手”角色的AI则可能解释更基础的概念。
When to use: This is useful when you want to influence the style or detail of the answer or get a certain perspective. For instance, an AI taking on an “expert” role might give a more advanced solution or more explanation, while a “beginner” role might make it explain more basic concepts.
例如:
Examples:
You are a Python instructor. Explain the following code and then modify it to be more Pythonic.
Act as a security analyst. Here’s some code. Identify any security vulnerabilities.
假设你是一个代码检查工具,负责检查代码风格问题。
Pretend you are a linter that checks code for style issues.
这会显著影响其响应。赋予人工智能安全分析师的角色可能会使其关注一些原本不会提及的内容(例如数据验证、安全编码实践或潜在漏洞)。赋予其讲师的角色则可能使其提供更清晰的解释,并且或许不会假定用户具备先验知识。
This can significantly affect the response. Assigning the AI a security analyst role might make it focus on things it otherwise wouldn’t mention (like data validation, secure coding practices, or potential vulnerabilities). An instructor role might make it provide clearer explanations and perhaps not assume prior knowledge.
在编程中,你可能会在索要代码之前说:
In coding, you might say before asking for code:
你是一位精通优化的 C++ 编程专家,正在指导一位初级开发人员。
You are an expert C++ programmer well-versed in optimization, instructing a junior developer.
最终成果可能会运用更高级的 C++ 特性,并解释做出某些选择的原因,在技术复杂性和教育清晰度之间取得平衡。
The result will likely use more advanced C++ features and explain why certain choices were made, balancing technical sophistication with educational clarity.
优点:这种技巧可以控制答案的语气和深度。它可以根据问题的复杂程度或详尽程度来调整解决方案。如果您想要一个非常简单的解决方案(让它扮演新手,它或许会避免使用复杂的技巧),或者一个非常优化的解决方案(让它扮演性能专家),那么这种技巧就非常有用。
Pros: This technique steers the tone and depth of the answer. This can tailor the solution to a certain level of complexity or thoroughness. It’s useful if you want either a very simple solution (tell it to act as a novice and maybe it’ll avoid complex tricks) or a very optimized one (tell it to act as a performance guru).
缺点:有时该模型可能会过于关注角色(例如,“讲师”可能会开始解释你已经知道的事情)。此外,一些人工智能安全系统对某些角色描述更为敏感——尤其是那些可能暗示欺骗、冒充权威或潜在有害活动的描述——尽管像“数据分析师”或“软件工程师”这样简单的技术和专业角色通常不会出现问题。
Cons: Sometimes the model might focus more on the persona than needed (an “instructor” might start explaining things you already know). Also, some AI safety systems are more sensitive to certain role descriptions—particularly those that might suggest deception, authority impersonation, or potentially harmful activities—though straightforward technical and professional roles like “data analyst” or “software engineer” typically work without issues.
情境提示是指在任务描述之外,向人工智能提供额外的情境或信息。除非你在提示符中提供(或者通过高级 IDE 集成中的上下文窗口提供),否则 AI 模型不会持久记忆你的整个项目。因此,如果你希望 AI 编写的代码能够融入你现有的代码库,就需要提供相关的上下文信息。简而言之,你需要在提示符中提供相关的数据或背景信息。
Contextual prompting means giving the AI additional context or information beyond the immediate task description. AI models don’t have persistent memory of your entire project unless you provide it in the prompt (or through some integrated context window in advanced IDE integrations). So if you want the AI to write code that fits into your existing codebase, give it that context. Basically, you supply relevant data or background as part of the prompt.
何时使用:当解决问题需要了解模型可能不知道或无法从训练中正确回忆起的特定数据或定义时,可以使用此功能。或者,当您想要确保与某些外部信息(例如 API 规范或之前的对话内容)保持一致时,也可以使用此功能。
When to use: Use when solving a problem requires knowing certain data or definitions that the model might not know or might not recall correctly from training. Or use when you want to ensure consistency with some external info (like an API spec or previous part of conversation).
例如:
Examples:
如果你有一个数据结构,并且想要编写能够使用它的代码,你可以粘贴它的定义:
If you have a data structure and you want code that works with it, you might paste its definition:
给定以下类,实现函数 X。
节点类:
def __init__(self, value, next=None):
self.value = value
self.next = next
现在编写一个函数,计算从头节点开始的链表中的节点数。Given the class below, implement the function X.
class Node:
def __init__(self, value, next=None):
self.value = value
self.next = next
# Now write a function to count the nodes in a linked list starting at head.
通过包含类定义,可以大大提高人工智能在其代码中正确使用Node.value类的可能性。Node.next
By including the class definition, you make the AI much more likely to use Node.value and Node.next properly in its code.
如果要使用特定的 API,请在提示中包含一段文档代码:
If you want to use a specific API, include a snippet of the documentation in the prompt:
使用 requests 库从 API 获取数据。(API 返回格式为 {...} 的 JSON 数据。)
Using the requests library, fetch the data from the API. (The API returns JSON with format: {...})
即使你提供文档中一个简短的 API 使用示例,人工智能也能模仿它。
If you include even a short example of API usage from docs, the AI can mimic it.
为了消除歧义:
For disambiguation:
用这个术语
student指代高中生,编写一个函数……
Using the term
studentto refer to high school students, write a function that…
如果学生的表达在语境中可能存在歧义,你已经澄清了这一点。
If student could be ambiguous in context, you’ve clarified it.
优点:您可以将人工智能与您关注的场景联系起来。如果您提供事实,它就不太可能做出错误的假设。如果人工智能可能无法记住或了解您的具体用例细节,这一点尤其有用。
Pros: You’re grounding the AI in the context you care about. It’s less likely to make wrong assumptions if you supply the facts. This is extremely helpful if the AI otherwise might not remember or know your specific use-case details.
缺点:这种方法会使提示信息更长。此外,模型有时可能会将提供的上下文直接复制到答案中(例如,如果不小心,可能会将文档片段中的某些行复制到代码中)。但通常情况下,它都能正确使用上下文信息。
Cons: This technique makes prompts longer. Also, the model might occasionally regurgitate the provided context into the answer (like copying lines from a documentation snippet into the code if not careful). But usually it uses it appropriately.
提示:如果上下文内容较多(例如大型模式或大量代码),有时最好对模型的关键要素进行概括,而不是逐字逐句地包含所有内容。这种方法有助于在上下文限制范围内操作,同时确保模型接收到最相关的信息。但是,如果内容足够少,则可以直接包含原文。
Tip: If you have a large context (like a big schema or many lines of code), sometimes it’s better to summarize the key elements for the model rather than including everything verbatim. This approach helps you stay within context limits while ensuring the model receives the most relevant information. However, if the content is small enough, just include it raw.
约束条件也是对……有用提及:性能约束(“优化至 O(n log n) 或更优”)、兼容性约束条件(例如“必须在 Python 3.8 上运行”)或库选择(例如“仅使用标准库,不得依赖外部库”),这些限制就像护栏一样,确保人工智能不会提出超出可接受范围的建议。
Constraints are also useful to mention: performance constraints (“Optimize for O(n log n) or better”), compatibility constraints (“Must run on Python 3.8”), or library choices (“Use standard library only, no external dependencies”). These act like guardrails and ensure the AI doesn’t suggest something outside acceptable bounds.
元提示是指给出关于输出本身的指令,而不仅仅是关于解决方案应该做什么的指令。这就像告诉人工智能如何格式化或处理解决方案一样。
Metaprompting is giving instructions about the output itself, not just what the solution should do. It’s like telling the AI how to format or approach the solution.
何时使用:当您需要特定格式或样式的答案,或者当您想要控制 AI 如何解决问题时,此功能非常有用。
When to use: Useful when you need the answer in a specific format or style or when you want to control how the AI works through the problem.
例如:
Examples:
首先,用两句话解释一下方法,然后提供代码。
First, explain the approach in two sentences, then provide the code.
这样可以确保人工智能不会直接运行代码:
This ensures the AI doesn’t launch straight into code:
解决方案中不要使用任何库。
Do not use any libraries in the solution.
这给解决方案施加了一个限制:
This places a constraint on the solution:
将输出格式化为 JSON 格式。
Format the output as JSON.
如果你使用人工智能来生成数据而不是代码,这将非常有用:
This is useful if you’re using the AI to produce data, not code:
只需提供函数体,无需定义行。
Only provide the function body, without the definition line.
如果您想将函数插入到现有代码中,这将非常方便:
This is handy if you want to insert the function into existing code:
如果输入无效,则不返回错误信息,而是返回 None。
If the input is invalid, instead of error, return None.
这并非确切的输出格式,但它指示人工智能在某些情况下应该如何行动。
This is not exactly the output format, but it’s instructing the AI how to behave for certain cases.
优点:您可以直接获得所需的内容,无需额外编辑。这在某些情况下至关重要。如果您计划在流程中自动使用 AI 的输出,那么格式的一致性就显得尤为重要。
Pros: You get exactly what you need, how you need it, without extra editing. This is crucial for some scenarios. If you plan to automatically use the AI’s output in a pipeline, then you really want consistent formatting.
缺点:如果指令与模型的默认风格冲突,有时模型可能只会部分遵循指令,或者你需要特别强调。例如,即使你明确说明“只有代码,没有解释”,模型有时也可能会包含一两句简短的注释。通常,使用直接的命令式语句会有帮助:
Cons: If the instructions conflict with the model’s default style, sometimes it might partially follow them or you have to emphasize them. For instance, even if you say “only code, no explanation,” occasionally the model might include a tiny comment or so. Usually, phrasing it as a direct imperative helps:
请勿包含任何解释;只需在单个代码块内输出代码即可。
Do not include any explanation; output only code inside a single code block.
GPT 等模型很好地遵循了这一点。
Models like GPT follow that quite well.
自我一致性与其说是一种提示风格,不如说是一种策略。其思路是针对同一提示获取多个输出,然后从中选择最佳或最常见的输出。正如Learn Prompting 的 Sander Schulhoff 所指出的,自洽性利用了这样一个概念:如果你多次询问模型(略带随机性),而它的许多答案都一致,那么这种共识很可能是正确的。
Self-consistency is more of a strategy than a prompt style. The idea is to get multiple outputs for the same prompt and then decide on the best or most common one. As Sander Schulhoff of Learn Prompting notes, self-consistency leverages the notion that if you ask the model multiple times (with slight randomness) and many of its answers agree, that consensus is likely correct.
何时使用:这对于复杂的难题非常有用,例如您不确定模型的第一个答案是否正确,尤其是在您自己无法轻松验证答案的情况下,或者如果您想通过查看 AI 是否反复给出相同的答案来检查其置信度。
When to use: This is useful for complex problems where you’re unsure the model’s first answer is correct, especially if you can’t verify it easily yourself, or if you want a confidence check from the AI by seeing whether it gives the same answer repeatedly.
手动操作方法:在某些平台(例如 ChatGPT)上,您可以点击“重新生成答案”。或者,您可以将题目复制到新的会话中,查看是否得到相同的结果。如果您得到三个答案,其中两个相同,一个不同,您可以采纳这两个不同的答案(假设该问题只有一个正确答案)。
How to use manually: On some platforms (like ChatGPT), you can click “Regenerate answer.” Or you can copy the prompt into a new session and see if it gives the same result. If you get three answers and two are the same and one is different, you might trust the two (assuming the problem has a single correct answer).
在编程语境中,如果生成的代码是针对确定性问题的,通常每次都会生成非常相似的代码(变量名或代码风格可能略有不同)。但如果是算法问题(例如“这段代码的输出是什么?”),则可以检查多次运行的结果。
In programming context, if it’s generating code for something deterministic, usually it will give very similar code each time (with small variations in variable names or style). But if it’s an algorithmic question (like “What’s the output of this code?”), you could check multiple runs.
这项技术在非编码任务(如逻辑谜题)中更为有效,但值得注意。
This technique is more powerful in noncoding tasks (like logic puzzles) but worth noting.
另一个角度——集合提示:实际上,你可以在一个提示中要求模型考虑多种可能性:
Another angle—ensemble prompting: You can actually ask the model within one prompt to consider multiple possibilities:
请给出该问题的两种不同解决方案。
Give two different solutions to this problem.
这样一来,你或许可以看看自己更喜欢哪一个,或者两个都试试。这就像是一次性实现了自我一致性,因为你可以得到多个答案。
Then perhaps you can see which one you like or test both. This is like self-consistency in one shot because you get multiple answers.
优点:如果多次尝试都收敛,这种方法可以增强对解决方案的信心。此外,它还能提供多种解决方案(如果您想从众多方案中选择最优雅的方案,这非常有用)。
Pros: This technique can increase confidence in the solution if multiple attempts converge. Also, you might get variety (which is good if you want to choose the most elegant solution among many).
缺点:进行多次调用并比较输出结果很耗时。
Cons: It’s time-consuming to do multiple calls and compare outputs.
实际上,如果我对某个答案不确定,我通常会换一种方式重新提问,看看是否能得到相同的答案。如果答案相同,我就更有信心它是正确的。
In practice, if I’m unsure about an answer, I’ll often repose the question differently to see if I get the same answer. If I do, I’m more confident it’s correct.
ReAct是一种更高级的提示技巧,它结合了推理和行动。它能够……模型不是它不仅像CoT那样进行思考,还能执行诸如计算、调用API或使用工具之类的操作。(更多信息请参阅ReAct Prompt工程指南)。在目前的实践中,这通常与LangChain等框架结合使用,人工智能可以输出一种特殊格式,程序将其解释为一个操作(例如要执行的命令或要运行的查询),然后将结果反馈给程序。
ReAct is a more advanced prompting technique that combines reasoning and acting. It gets the model not only to think, like CoT does, but also to take actions like making a calculation, calling an API, or using a tool. (See the ReAct Prompt Engineering Guide for more). In current practice, this is often used with frameworks like LangChain, where the AI can output a special format that a program interprets as an action (like a command to execute or a query to run), then feed the result back.
就我们目前的情况而言(循环中没有这样的执行环境),您仍然可以通过指示 AI 首先制定计划,然后输出结果来实现 ReAct 的一种形式。它类似于 CoT,但专门用于使用工具或执行子任务。
For our scope (without such an execution environment in the loop), you can still do a form of ReAct by instructing the AI to first outline a plan, then output the result. It’s similar to CoT but specifically oriented to using tools or performing subtasks.
例子:
Example:
使用 Python 确定巴黎的当前天气并打印出来。
Using Python, determine the current weather in Paris and print it.
除非人工智能具备浏览能力,否则它无法真正获取当前天气信息。ReAct 方法会首先让人工智能通过以下方式来推理问题:
Unless the AI has browsing capabilities, it cannot truly get the current weather. A ReAct approach would have the AI first reason through the problem by stating:
我需要获取巴黎的实时天气数据,这需要调用天气 API。
I need to access current weather data for Paris, which requires calling a weather API.
然后,人工智能会尝试使用可用的工具发起 API 调用。如果成功,它将收到实际的天气数据;如果没有可用的工具,它可能会承认这一限制或使用假设数据。最后,人工智能会编写 Python 代码来显示天气信息,并将通过推理和行动过程获得的所有数据整合到代码中。
The AI would then attempt to use an available tool to make this API call. If successful, it would receive actual weather data; if no such tool is available, it might acknowledge the limitation or work with hypothetical data. Finally, the AI would write the Python code to display the weather information, incorporating whatever data it was able to obtain through this reasoning and action process.
如果无法访问外部工具,ReAct 对于简单的提示任务可能并不适用。然而,在评估组织使用的 AI 工具时,能否从互联网访问最新信息是一项至关重要的能力评估。许多 AI 模型都存在知识截止点,这意味着它们的训练数据仅涵盖特定日期,这可能导致在快速变化的主题上出现过时的信息。
Without external tool access, ReAct might not be particularly relevant for simple prompting tasks. However, when evaluating AI tools for your organization, determining whether they can access current information from the internet represents a critical capability assessment. Many AI models operate with knowledge cutoffs, meaning their training data only extends to a specific date, which can result in outdated information for rapidly changing topics.
如果您使用的环境允许 AI 执行代码(例如 Jupyter 集成或类似平台),则可以通过指示系统来实现 ReAct:
If you are using an environment where the AI can execute code (such as Jupyter integrations or similar platforms), you could implement ReAct by instructing the system:
首先为该函数编写测试,运行测试,然后根据测试结果调整代码。
First write a test for this function, run it, then adjust the code accordingly.
这通过推理步骤(编写测试)、执行操作(执行测试)以及根据结果调整代码,展示了 ReAct 模式。然而,仅通过提示来协调此类工作流程需要高级提示技术和相应的技术基础设施。
This demonstrates the ReAct pattern through a reasoning step (writing the test), followed by an action (executing the test), and then code adjustment based on the results. However, orchestrating such workflows through pure prompts requires advanced prompting techniques and appropriate technical infrastructure.
更简单的用法:您可以模拟问答环节,其中人工智能会执行模拟操作的中间步骤:
Simpler use: You can simulate a Q&A where the AI has intermediate steps that mimic actions:
一步一步地思考,必要时进行计算。
Think step-by-step and if you need to, do calculations.
It’s effectively CoT but with a more imperative tone.
优点:在条件允许的情况下,它可以解决需要外部信息或迭代试验的问题(例如,人工智能可以通过实际运行代码来纠正自身错误)。在调试环境中,能够执行代码进行测试的人工智能非常出色。
Pros: When available, it can solve problems that require external info or iterative trial (like the AI can correct itself by actually running code). In debugging contexts, an AI that can execute code to test it is fantastic.
缺点:如果没有专门的工具,这种技术很难广泛应用。而且,如果只是在普通的 ChatGPT 中这样提示,它要么会想象这些操作,要么直接执行 CoT(上下文无关文本)。
Cons: This technique is not widely accessible without specific tooling. And if you just prompt that way in plain ChatGPT, it will either imagine the actions or just do CoT.
就我们的提示写作而言,请记住,虽然存在一些系统(例如 OpenAI 的工具使用代理或其他系统),但在普通的提示中,我们主要进行 CoT,并且我们自己处理运行代码或测试等操作。
For our purposes in prompt writing, keep in mind that some systems (like OpenAI’s tool-using agents or others) exist, but in vanilla prompting we mostly do CoT, and we ourselves handle actions like running the code or tests.
提示技巧可以结合使用。例如,你可以设计一个包含几个提示的短视频,并在示例中演示 CoT(认知能力)。或者,你也可以将角色与 CoT 结合起来:
Prompting techniques can be combined. For instance, you might do a few-shot prompt that also demonstrates CoT in the examples. Or you might combine a role with CoT:
作为高级工程师,要一步一步地思考问题,然后再编写代码。
As a senior engineer, think step-by-step through the problem, then give the code.
既然我们已经探索了各种提示技术,让我们通过一两个场景来看看它们是如何运作的,然后讨论如何审查和改进 AI 的输出(这将引出下一章,即理解和拥有生成的代码)。
Now that we’ve explored various prompting techniques, let’s see them in action with a scenario or two, then discuss how to review and refine the AI’s output (which leads into the next chapter about understanding and owning the generated code).
假设你有一个功能无法正常工作。你可能会结合使用角色提示和 CoT 提示:
Imagine you have a function that isn’t working. You might use a combination of role and CoT prompting:
你是一名Python调试员。让我们一步一步地找出以下代码中的错误。
You are a Python debugger. Let’s think step-by-step to find the bug in the following code.
接下来是代码。人工智能可能会逐行分析代码,并找出错误所在。
This would be followed by the code. The AI might respond with an analysis of each line and pinpoint the bug.
或者假设你想为一个稍微复杂一些的算法生成代码,确保代码注释完整,并为其编写测试用例。一个综合性的提示可能如下所示:
Or let’s say you want to generate code for a somewhat complex algorithm, ensure it’s well commented, and also get test cases for it. A combined prompt might look like this:
您是一位经验丰富的 Python 开发人员。让我们一步一步地解决这个问题。我们需要一个函数
merge_sorted_lists(list1, list2),将两个已排序的列表合并成一个已排序的列表。首先,解释一下思路,然后提供带有注释的 Python 代码。最后,给出2-3 个示例代码来验证其有效性。
You are an expert Python developer. Let’s solve this step-by-step. We need a function
merge_sorted_lists(list1, list2)that merges two sorted lists into one sorted list. First, explain the approach, then provide the Python code with comments. After that, give 2–3 example tests in code to demonstrate it works.
这条提示信息非常全面。第一句话说明了角色。第二句话要求逐步阐述推理过程。第三句话给出了主要任务。第四句话要求编写带有注释的代码,第五句话甚至要求编写测试。
This single prompt is quite comprehensive. The first sentence sets a role. The second requests step-by-step reasoning. The third gives the main task. The fourth sentence asks for code with explanatory comments, and the fifth even asks for tests.
人工智能随后可能会输出一段解释,然后是带有注释的代码,最后是一些测试用例。这是一种高级用法,但它展示了如何引导人工智能做出多方面的响应。
The AI might then output an explanation, then the code with inline comments, then some test cases at the end. This is an advanced use, but it shows how you can direct the AI through a multifaceted response.
高效的工程设计还包括知道什么问题不应该问以及如何避免陷阱。如果提示信息过长或包含过多指令,模型可能会出现混乱或截断部分输出。如果发现模型开始忽略提示信息的部分内容,则需要简化提示信息或将其拆分成多个部分。如果人工智能模型有时会生成错误的事实或代码(即出现“臆想”),则需要进行复核,不要将其视为绝对真理。如果发现模型倾向于生成过于冗长的代码,可以预先指示“尽可能使解决方案简洁”。如果模型有时会使用不存在的函数,则可以指示“仅使用以下列出的 API 函数”,并列出这些函数。你越了解人工智能的行为,就越能调整你的提示,从而克服任何弱点。
Prompt engineering also involves knowing what not to ask and how to avoid pitfalls. If a prompt is getting too large or includes too many instructions, the model might get confused or truncate some output. If you find it starts ignoring parts of your prompt, you might need to simplify or do it in parts. If an AI model sometimes produces incorrect facts or code (it “hallucinates”), you learn to double-check and not use it as a factual oracle. If you find it tends to give overly verbose code, you can preempt that with “Make the solution as concise as possible.” If it sometimes uses functions that don’t exist, you might instruct, “Use only the API functions listed below” and list them. The better you understand the AI’s behavior, the more you can mold your prompts to get around any weaknesses.
如果任务非常复杂,你也可以将其分解成多个子任务交给人工智能处理。例如,你可以先提示:
If a task is very complex, you can also break it into subtasks for the AI. For example, you might first prompt:
列出实现简单算术表达式语言的基本编译器的步骤。
List the steps to implement a basic compiler for a simple arithmetic expression language.
人工智能给出步骤后,你需要根据单独的提示完成每个步骤,甚至可以在单独的文件或会话中进行:
Once the AI gives the steps, you tackle each step with separate prompts, maybe even in separate files or sessions:
现在执行步骤 1:分词。
Now implement step 1: tokenization.
这就像利用人工智能进行系统设计:你可以先勾勒出轮廓,然后逐步完善每个部分。它充分利用了人工智能辅助规划(而不仅仅是编码)的能力。
This is like doing system design with the AI: you can outline then refine each piece. It leverages the AI’s ability to assist in planning (not just coding).
在聊天环境中,你会有一个对话历史记录,称为状态。你可以通过与人工智能对话来构建上下文。在 IDE 代码补全环境中,上下文主要来源于文件内容和注释。两者都以不同的方式提供累积上下文信息。如果需要 AI 记住之前说过的话(例如完善答案),请使用对话模式。如果希望确保 AI 只关注当前相关的内容,请使用全新提示或文件上下文。有时,清除上下文可以防止模型固守先前可能错误的假设。
In a chat setting, you have a conversation history, known as state. You can build up context by discussing with the AI. In an IDE completion setting, the context is mostly your file content and comments. Both allow cumulative context in different ways. Use conversation if you need the AI to remember what was said (like refining an answer). Use fresh prompts or file context if you want to ensure it’s focusing only on what’s relevant now. Sometimes wiping away the context prevents the model from sticking to a potentially wrong earlier assumption.
通过在各种实例上练习这些技巧,你将熟练掌握何时使用哪种方法:
By practicing with these techniques on various examples, you’ll become adept at knowing which approach to use and when:
如果输出格式很重要,请给出示例(少量示例)或明确的格式说明。
If output format is important, give examples (few shot) or explicit formatting instructions.
如果逻辑比较复杂,可以使用CoT方法或分步讲解法。
If logic is tricky, use CoT or step-by-step.
如果解决方案的质量可能参差不齐,可以设定一个角色(例如“经验丰富的工程师”)来获得更好的方案。
If the solution can vary in quality, set a role (like “seasoned engineer”) to get a better style.
如果模型不遵守规定,或许可以把提示拆分成几个部分,简化它们,或者使用更强烈的措辞来描述限制条件。
If the model isn’t complying, maybe break your prompts into pieces, simplify them, or use stronger wording for constraints.
并非所有提示都具有相同的价值。目前我们已经看到了很多有效的提示示例,但识别反模式——导致人工智能响应不佳的常见错误——同样具有指导意义。本节将介绍一些常见的提示失败案例以及如何解决这些问题。
Not all prompts are created equal. By now, we’ve seen numerous examples of effective prompts, but it’s equally instructive to recognize antipatterns—common mistakes that lead to poor AI responses. This section covers some frequent prompt failures and how to fix them.
这是典型的“它不起作用,请修复它”或“编写一个能实现 X 的功能”之类的语句,缺乏足够的细节。“为什么我的函数不起作用?”这个问题通常会得到无用的答案。模糊的提示会迫使人工智能猜测上下文,往往导致给出通用建议或无关代码。
This is the classic “It doesn’t work, please fix it” or “Write something that does X” without enough detail. The question “Why isn’t my function working?” will generally get a useless answer. Vague prompts force the AI to guess the context and often result in generic advice or irrelevant code.
解决方法很简单:添加上下文和具体信息。如果你发现自己问了一个问题,而答案却像“你试过检查 X 吗?”一样模棱两可,那就停下来,重新组织你的问题,添加更多细节(错误信息、代码片段、预期结果与实际结果的对比等等)。一个好方法是阅读你的问题,然后问自己:“这个问题是否适用于几十种不同的场景?”如果答案是肯定的,那就说明问题太笼统了。你需要将问题具体化,使其仅适用于你遇到的情况。
The fix is straightforward: add context and specifics. If you find yourself asking a question and the answer feels like a Magic 8–Ball response (“Have you tried checking X?”), stop and reframe your query with more details (error messages, code excerpt, expected versus actual outcome, etc.). A good practice is to read your prompt and ask, “Could this question apply to dozens of different scenarios?” If the answer is yes, it’s too vague. Make it so specific that it could only apply to your scenario.
This is the opposite issue: asking the AI to do too many things at once. For instance:
生成一个完整的 Node.js 应用程序,包括身份验证、React 前端和部署脚本。
Generate a complete Node.js app with authentication, a frontend in React, and deployment scripts.
或者,规模更小一些:
Or even, on a smaller scale:
一次性修复这 5 个漏洞并添加这 3 个功能。
Fix these 5 bugs and also add these 3 features in one go.
人工智能可能会尝试,但结果可能杂乱无章或不完整,甚至会忽略请求的某些部分。即使它能处理所有问题,响应也会很长,而且更难验证。
The AI might attempt it, but you’ll likely get a jumbled or incomplete result, or it might ignore some parts of the request. Even if it addresses everything, the response will be long and harder to verify.
解决方法是将任务拆分。优先处理:一次只做一件事,正如我们之前强调的。这样更容易发现错误,并确保模型始终保持专注。如果你发现自己写的段落中多次使用了“和”,请考虑将其拆分成单独的提示或步骤。
The remedy is to split the tasks. Prioritize: do one thing at a time, as we emphasized earlier. This makes it easier to catch mistakes and ensures the model stays focused. If you catch yourself writing a paragraph that uses “and” multiple times in the instructions, consider breaking it into separate prompts or sequential steps.
有时用户会提出很多他们提供信息,但从不明确提问或说明需求,比如直接抛出一大段代码,然后说:“这是我的代码。” 这会让人工智能感到困惑——它不知道你想要什么。
Sometimes users will present a lot of information but never clearly ask a question or specify what they need, like dumping a large code snippet and just saying, “Here’s my code.” This can confuse the AI—it doesn’t know what you want.
务必提出明确的要求:
Always include a clear ask:
找出上述代码中的任何错误。
Identify any bugs in the above code.
请解释这段代码的功能。
Explain what this code does.
完成代码中的待办事项。
Complete the to-dos in the code.
提示信息应该有明确的目的。如果只是提供文本而没有提出问题或给出指示,人工智能可能会做出错误的假设(例如,总结代码而不是修复它等等)。务必确保人工智能明白你为什么向它展示这段代码。即使是像“这段代码有什么问题?”或“请继续实现这个函数”这样简单的补充说明也能为它指明方向。
A prompt should have a purpose. If you just provide text without a question or instruction, the AI might make incorrect assumptions (like summarizing the code instead of fixing it, etc.). Make sure the AI knows why you showed it some code. Even a simple addition like “What’s wrong with this code?” or “Please continue implementing this function” gives it direction.
这是一个很微妙的例子。有时你可能会提出优化或改进的要求,但却没有明确定义成功的标准——例如,“让这个函数运行得更快”。更快的标准是什么?如果人工智能不了解你的性能限制,它可能会进行一些无关紧要的微优化,或者采用理论上更快但实际上提升微乎其微的方法。又比如,“让这段代码更简洁”:“更简洁”是一个主观概念。我们通过明确设定目标来解决这个问题,例如“减少重复代码”或“改进变量名”等等。
This is a subtle one. Sometimes you might ask for an optimization or improvement, but you don’t define what success looks like—for example, “Make this function faster.” Faster by what metric? If the AI doesn’t know your performance constraints, it might micro-optimize something that doesn’t matter or use an approach that’s theoretically faster but practically negligible. Or “Make this code cleaner”: “cleaner” is subjective. We dealt with this by explicitly stating goals like “reduce duplication” or “improve variable names,” etc.
解决方法:量化或定性改进效果:
The fix: quantify or qualify the improvement:
优化此函数,使其运行时间呈线性(当前版本为二次方)。
Optimize this function to run in linear time (current version is quadratic).
重构这段代码,移除全局变量,改用类。
Refactor this to remove global variables and use a class instead.
简而言之,要明确说明你通过重构或添加新功能要解决什么问题。如果描述过于模糊,人工智能可能会解决与你关心的问题不同的问题。
Basically, be explicit about what problem you’re solving with the refactor or feature. If you leave it too open, the AI might solve a different problem than the one you care about.
Sometimes the AI might respond with a clarifying question or an assumption:
你使用的是 React 类组件还是函数组件?
Are you using React class components or functional components?
我假设输入的是字符串——请确认。
I assume the input is a string—please confirm.
如果你忽略这些提示,只是重复你的请求,你就错失了改进提示信息的机会。人工智能正在发出信号,表明它需要更多信息。务必回答它的问题,或者完善你的提示信息,使其包含这些细节。
If you ignore these and just reiterate your request, you’re missing an opportunity to improve the prompt. The AI is signaling that it needs more info. Always answer its questions or refine your prompt to include those details.
此外,如果 AI 的输出明显错误(例如,它误解了问题),不要只是逐字逐句地重试相同的提示。花点时间调整一下你的措辞。也许你的提示语里有模棱两可的词语,或者遗漏了某些关键信息。把它想象成一次对话:如果人类听不懂,你会用不同的方式解释;对人工智能也一样。
Additionally, if the AI’s output is clearly off (like it misunderstood the question), don’t just retry the same prompt verbatim. Take a moment to adjust your wording. Maybe your prompt had an ambiguous phrase or omitted something essential. Treat it like a conversation: if a human misunderstood, you’d explain differently; do the same for the AI.
如果你不断改变提问方式或一次性混合使用不同的格式,模型可能会感到困惑。例如,在指令中频繁切换第一人称和第三人称,或者以令人困惑的方式将伪代码与实际代码混合在一起。
If you keep changing how you ask or mixing different formats in one go, the model can get confused. Two examples include switching between first person and third person in instructions or mixing pseudocode with actual code in a confusing way.
尽量在同一提示中保持一致的风格。如果您提供示例,请确保它们清晰明确(例如,使用 Markdown 的三个反引号表示代码,使用引号表示输入/输出示例等)。保持一致性有助于模型正确理解您的意图。此外,如果您有偏好的风格(例如,ES6 或 ES5 语法),请务必始终明确说明;否则,模型可能会在同一个提示中给出不同的建议。
Try to maintain a consistent style within a single prompt. If you provide examples, ensure they are clearly delineated (use Markdown triple backticks for code, quotes for input/output examples, etc.). Consistency helps the model parse your intent correctly. Also, if you have a preferred style (say, ES6 versus ES5 syntax), consistently mention it; otherwise, the model might suggest one way in one prompt and another way later.
使用聊天时,如果您说“上述函数”或“之前的输出”,请确保指代对象明确。如果对话时间很长,当你说“重构上面的代码”时,人工智能可能会失去思路,或者选择错误的代码片段进行重构。
When using chat, if you say “the above function” or “the previous output,” be sure the reference is clear. If the conversation is long and you say, “Refactor the above code,” the AI might lose track or pick the wrong code snippet to refactor.
更安全的做法是再次引用代码或明确指出需要重构的函数。模型的注意力窗口有限,虽然许多低级模型可以引用对话的先前部分,但再次提供明确的上下文有助于避免混淆。如果代码展示后已经过去了一段时间(或几条消息),这一点尤其重要。
It’s safer to either quote the code again or specifically name the function you want refactored. Models have a limited attention window, and although many LLMs can refer to prior parts of the conversation, giving it explicit context again can help avoid confusion. This is especially true if some time (or several messages) passed since the code was shown.
提示的艺术是不断迭代和创造性的。随着模型的演进,提示的最佳实践可能会改变(例如,未来的模型或许能用更少的文字更好地理解意图)。但其基本原则始终不变:有效沟通,人工智能就能更好地为你服务。
The art of prompting is iterative and creative. As models evolve, prompt best practices might change (for instance, future models might better understand intent with less wording). But the underlying principle remains: communicate effectively, and the AI will serve you better.
本质上,掌握提示设计就像掌握一门新的编程语言——人工智能的指令语言。它融合了技术写作、前瞻性思维以及对提示本身的交互式调试。一旦你熟练掌握了这项技能,人工智能就会真正成为你思维的延伸,因为你可以可靠地提取出你设想的解决方案(甚至是你尚未完全构思但可以引导人工智能发现的解决方案),而且几乎毫不费力。这项技能很可能会像会使用谷歌搜索或调试器一样成为必备技能——在如今这个“氛围编程”时代,它是现代开发者必备的技能之一。
In essence, mastering prompt engineering is like mastering a new programming language—the language of instructions for AI. It’s a blend of technical writing, foresight, and interactive debugging of the prompt itself. But once you get good at it, the AI truly starts to feel like an extension of your own mind, because you can reliably extract the solutions you envision (or even those you don’t fully envision yet but can guide the AI to discover) with minimal friction. This skill will likely become as fundamental as knowing how to google things or how to use a debugger—it’s part of the modern developer’s skill set in the age of vibe coding.
如果人工智能可以解决大约 70% 的问题,那么作为编码伙伴,你该如何与它合作?第三章探讨了开发者如何真正使用人工智能,并提出了一些“黄金法则”,以促进代码的流畅运行。
If AI can solve about 70% of a problem, how do you approach it as a partner in coding? Chapter 3 looks at how developers really use AI and sets out some “golden rules” for vibe coding.
基于人工智能的编码工具在某些任务上表现出色。它们在这方面尤为突出。擅长编写样板代码、编写例行函数,以及将项目推进到接近完成的状态。事实上,许多开发者发现,人工智能助手可以实现初步解决方案,满足大约 70% 的需求。
AI-based coding tools are astonishingly good at certain tasks.1 They excel at producing boilerplate, writing routine functions, and getting projects most of the way to completion. In fact, many developers find that an AI assistant can implement an initial solution that covers roughly 70% of the requirements.
Peter Yang在 X 上的一篇文章中完美地概括了我一直在实地观察到的情况:
Peter Yang perfectly captured what I’ve been observing in the field in a post on X:
作为一名非工程师,我对目前为止使用人工智能进行编程的一些真实感想:
它能帮你完成70%的目标,但剩下的30%却令人沮丧。它总是前进一步,后退两步,不断出现新的漏洞和问题。
如果我知道代码的工作原理,我或许可以自己修复它。但既然我不了解,我就怀疑自己是否真的学到了多少东西。
Honest reflections from coding with AI so far as a non-engineer:
It can get you 70% of the way there, but that last 30% is frustrating. It keeps taking one step forward and two steps backward with new bugs, issues, etc.
If I knew how the code worked I could probably fix it myself. But since I don’t, I question if I’m actually learning that much.
非工程专业的程序员在使用人工智能进行编程时,常常会遇到令人沮丧的瓶颈。他们或许能很快完成70%的工作,但剩下的30%却会面临收益递减的困境。
Nonengineers using AI for coding find themselves hitting a frustrating wall. They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns.
这个“70%难题”揭示了当前人工智能辅助开发的一个关键问题。最初的进展令人感觉神奇:你只需描述你的需求,像v0或Bolt这样的人工智能工具就能生成一个看起来很棒的工作原型。但随后现实就会给你当头一棒。
This “70% problem” reveals something crucial about the current state of AI-assisted development. The initial progress feels magical: you can describe what you want, and AI tools like v0 or Bolt will generate a working prototype that looks impressive. But then reality sets in.
这70%通常是工作中简单直接、模式化的部分——遵循既定路径或常用框架的代码。正如一位Hacker News评论者所指出的,人工智能非常擅长处理软件的“偶然复杂性”(重复性的机械工作),而“本质复杂性”(理解和管理问题固有的复杂性)则仍然需要人类的参与。用弗雷德·布鲁克斯的经典术语来说,人工智能解决的是开发过程中偶然出现的难题,而非其本质的难题。
The 70% is often the straightforward, patterned part of the work—the kind of code that follows well-trod paths or common frameworks. As one Hacker News commenter observed, AI is superb at handling the “accidental complexity” of software (the repetitive, mechanical stuff), while the “essential complexity”—understanding and managing the inherent complexity of a problem—remains on human shoulders. In Fred Brooks’s classic terms, AI tackles the incidental but not the intrinsic difficulties of development.
这些工具在哪些方面存在不足?经验丰富的工程师们一致认为存在“最后一公里”的差距。人工智能可以生成看似合理的解决方案,但最后30%的工作——包括处理极端情况、完善架构以及确保可维护性——“需要大量的专业知识”。
Where do these tools struggle? Experienced engineers consistently report a “last mile” gap. AI can generate a plausible solution, but the final 30%—covering edge cases, refining the architecture, and ensuring maintainability—“needs serious human expertise.”
例如,人工智能可能会提供一个在基本场景下技术上可行的函数,但除非明确指定,否则它不会自动处理异常输入、竞争条件、性能限制或未来需求。人工智能可以帮你完成大部分工作,但最后那至关重要的30%(处理极端情况、保持系统可维护性和构建稳固的架构)需要丰富的专业知识。
For example, an AI might give you a function that technically works for the basic scenario, but it won’t automatically account for unusual inputs, race conditions, performance constraints, or future requirements unless explicitly told. AI can get you most of the way there, but that final crucial 30% (edge cases, keeping things maintainable, and solid architecture) needs serious human expertise.
此外,人工智能它有一种众所周知的倾向,即生成看似合理实则错误的输出。它可能会引入一些不易察觉的错误,或者“臆想”出一些根本不存在的函数和库。史蒂夫·耶格(Steve Yegge)曾略带讽刺地将如今的LLM比作“高产的初级开发人员”——他们速度惊人、热情洋溢,但“可能嗑了药”,容易炮制出一些疯狂或行不通的方案。
Moreover, AI has a known tendency to generate convincing but incorrect output. It may introduce subtle bugs or “hallucinate” nonexistent functions and libraries. Steve Yegge wryly likens today’s LLMs to “wildly productive junior developers”—incredibly fast and enthusiastic but “potentially whacked out on mind-altering drugs,” prone to concocting crazy or unworkable approaches.
用Yegge 的话来说,LLM(生命周期管理)程序可以生成乍看之下完美无瑕的代码,但如果经验不足的开发者天真地认为“看起来不错!”并照搬执行,那么接下来的几周就会出现各种滑稽可笑(或灾难性后果)的情况。人工智能并没有真正理解问题;它只是将一些看似合理的模式拼凑在一起。只有人类才能辨别出看似完美的解决方案是否隐藏着长期的隐患。Simon Willison 也表达了类似的观点,他曾看到人工智能提出了一个极其巧妙的设计方案,但只有对问题有深刻理解的高级工程师才能看出其中的缺陷。由此可见:人工智能的自信远远超过了其可靠性。
In Yegge’s words, an LLM can spew out code that looks polished at first glance, yet if a less-experienced developer naively says, “Looks good to me!” and runs with it, hilarity (or disaster) ensues in the following weeks. The AI doesn’t truly understand the problem; it stitches together patterns that usually make sense. Only a human can discern whether a seemingly fine solution hides long-term landmines. Simon Willison echoed this after seeing an AI propose a bewitchingly clever design that only a senior engineer with deep understanding of the problem could recognize as flawed. The lesson: AI’s confidence far exceeds its reliability.
至关重要的是,目前的人工智能并没有创造出超越其训练数据的新抽象概念或策略。它们不会为你发明全新的算法或创新的架构——它们只是对已知事物进行重新组合。它们也不会为决策负责。正如一位工程师所指出的,“人工智能并没有比训练数据中更好的想法。它们不会为自己的工作负责。”
Crucially, current AIs do not create fundamentally new abstractions or strategies beyond their training data. They won’t invent a novel algorithm or an innovative architecture for you—they remix what’s known. They also won’t take responsibility for decisions. As one engineer noted, “AIs don’t have ‘better ideas’ than what their training data contains. They don’t take responsibility for their work.”
这一切都意味着,创造性思维和分析性思维——决定建造什么、如何构建以及为什么——仍然是人类的领域。总而言之,人工智能是开发人员的得力助手,它能处理70%的重复性工作,并极大地提升我们的生产力。但它并非万能灵药,无法取代人类的判断。软件工程中剩余的30%——也就是那些真正困难的部分——仍然需要训练有素、思维缜密的开发人员才能掌握的技能。这些才是真正需要关注的持久技能,本书第四章将专门探讨这些技能。正如一次讨论中所说:“人工智能是一个强大的工具,但它并非万能灵药……人类的判断和良好的软件工程实践仍然至关重要。”
All of this means that creative and analytical thinking—deciding what to build, how to structure it, and why—firmly remains a human domain. In summary, AI is a force multiplier for developers, handling the repetitive 70% and giving us a “turbo boost” in productivity. But it is not a silver bullet that can replace human judgment. The remaining 30% of software engineering—the hard parts—still requires skills that only trained, thoughtful developers can bring. Those are the durable skills to focus on, and Chapter 4 is dedicated to them. As one discussion put it: “AI is a powerful tool, but it’s not a magic bullet.…Human judgment and good software engineering practices are still essential.”
我观察到两种截然不同的模式团队如何利用人工智能进行开发,我们不妨称他们为“引导者”和“迭代者”。两者都在帮助工程师(甚至非技术用户)缩短从想法到执行(或最小可行产品)的差距。
I’ve observed two distinct patterns in how teams are leveraging AI for development. Let’s call them the “bootstrappers” and the “iterators.” Both are helping engineers (and even nontechnical users) reduce the gap from idea to execution (or MVP).
首先是自启动团队,他们通常负责从零开始构建一个新项目,最终实现最小可行产品(MVP)。像 Bolt、v0 和截图转代码人工智能这样的工具正在彻底改变这些团队启动新项目的方式。这些团队通常:
First, there are the bootstrappers, who are generally taking a new project from zero to MVP. Tools like Bolt, v0, and screenshot-to-code AI are revolutionizing how these teams bootstrap new projects. These teams typically:
先从设计或粗略概念入手。
Start with a design or rough concept
利用人工智能生成完整的初始代码库
Use AI to generate a complete initial codebase
只需几小时或几天就能拿到可用的原型,而不是几周。
Get a working prototype in hours or days instead of weeks
专注于快速验证和迭代
Focus on rapid validation and iteration
结果令人印象深刻。我最近亲眼目睹一位独立开发者使用 Bolt,几乎瞬间就将 Figma 设计稿转化成了一个可运行的 Web 应用。虽然它还未达到正式上线标准,但足以收集到初步的用户反馈。
The results can be impressive. I recently watched a solo developer use Bolt to turn a Figma design into a working web app in next to no time. It wasn’t production-ready, but it was good enough to get very initial user feedback.
第二类开发者,即迭代者,在日常开发流程中使用 Cursor、Cline、Copilot 和 Windsurf 等工具。这种方式虽然不那么炫酷,但可能更具变革性。这类开发者包括:
The second camp, the iterators, uses tools like Cursor, Cline, Copilot, and Windsurf for their daily development workflow. This is less flashy but potentially more transformative. These developers are:
利用人工智能进行代码补全和建议
Using AI for code completion and suggestions
利用人工智能完成复杂的重构任务
Leveraging AI for complex refactoring tasks
生成测试和文档
Generating tests and documentation
利用人工智能作为“结对程序员”来解决问题
Using AI as a “pair programmer” for problem solving
但问题在于:虽然这两种方法都能显著加快开发速度,但它们也存在一些不易察觉的隐性成本。
But here’s the catch: while both approaches can dramatically accelerate development, they come with hidden costs that aren’t immediately obvious.
当你观看资深工程师使用 Cursor 或 Copilot 等 AI 工具时,你会觉得这简直像魔法一样。他们能在几分钟内搭建出完整的功能框架,包括测试和文档。但仔细观察,你会发现一个关键点:他们并非只是被动地接受 AI 的建议。他们会不断地将生成的代码重构为更小、更专注的模块。他们会添加 AI 遗漏的全面错误处理和边界情况处理,强化其类型定义和接口,并质疑其架构决策。换句话说,他们运用多年积累的工程经验来塑造和约束 AI 的输出。AI 加速了他们的实现,但正是他们的专业知识保证了代码的可维护性。
When you watch a senior engineer work with AI tools like Cursor or Copilot, it looks like magic. They can scaffold entire features in minutes, complete with tests and documentation. But watch carefully, and you’ll notice something crucial: they’re not just accepting what the AI suggests. They’re constantly refactoring the generated code into smaller, focused modules. They’re adding comprehensive error handling and edge-case handling the AI missed, strengthening its type definitions and interfaces, and questioning its architectural decisions. In other words, they’re applying years of hard-won engineering wisdom to shape and constrain the AI’s output. The AI is accelerating their implementation, but their expertise is what keeps the code maintainable.
初级工程师常常会忽略这些关键步骤。 他们更容易接受人工智能的输出,导致我称之为“纸牌屋代码”——它看起来很完整,但在现实世界的压力下会崩溃。
Junior engineers often miss these crucial steps. They accept the AI’s output more readily, leading to what I call “house of cards code”—it looks complete but collapses under real-world pressure.
接下来通常会发生什么?遵循一种我称之为可预测的反模式“后退两步”模式(如图 3-1所示):
What typically happens next follows a predictable antipattern I call the “two steps back” pattern (shown in Figure 3-1):
你试图修复一个小漏洞。
You try to fix a small bug.
人工智能提出的修改建议似乎很合理。
The AI suggests a change that seems reasonable.
这个修复方案又会引发其他问题。
This fix breaks something else.
你要求人工智能修复新问题。
You ask AI to fix the new issue.
这又会引发两个问题。
This creates two more problems.
冲洗并重复。
Rinse and repeat.
对于非工程师来说,这种循环尤其痛苦,因为他们缺乏理解问题根源的思维模式。经验丰富的开发人员遇到 bug 时,可以凭借多年的模式识别经验推断出潜在的原因和解决方案。如果没有这种背景知识,你就像是在玩打地鼠游戏,对着自己并不完全理解的代码徒劳无功。这就是我在本书序言中提到的“知识悖论”:资深工程师和开发人员使用人工智能来加速他们已经知道如何做的事情,而初级工程师则试图利用人工智能来学习该做什么。
This cycle is particularly painful for nonengineers because they lack the mental models to understand what’s actually going wrong. When an experienced developer encounters a bug, they can reason about potential causes and solutions based on years of pattern recognition. Without this background, you’re essentially playing whack-a-mole with code you don’t fully understand. This is the “knowledge paradox” I mentioned back in this book’s preface: senior engineers and developers use AI to accelerate what they already know how to do, while juniors try to use it to learn what to do.
对于以“引导式”模式使用人工智能的非工程师来说,这种循环尤其痛苦,因为他们缺乏构建最小可行产品(MVP)时解决这些问题所需的思维模型。然而,即使是经验丰富的“迭代者”,如果过度依赖人工智能的建议而没有进行深入验证,也可能陷入这种“打地鼠”式的困境。
This cycle is particularly painful for nonengineers using AI in a “bootstrapper” pattern, because they lack the mental models needed to address these issues building their MVP. However, even experienced “iterators” can fall into this whack-a-mole trap if they overly rely on AI suggestions without deep validation.
这里存在一个更深层次的问题:人工智能编码工具之所以能够被非工程师使用——因为它们能够代表你处理复杂性——实际上可能会阻碍学习。如果代码只是“凭空出现”,而你却不理解其底层原理,你就无法培养调试技能,也无法学习基本模式。你无法理解架构决策,因此维护和改进代码会变得异常艰难。这会造成一种依赖关系,你需要不断地求助于人工智能模型来解决问题,而不是培养自己解决问题的专业知识。
There’s a deeper issue here: the very thing that makes AI coding tools accessible to nonengineers—their ability to handle complexity on your behalf—can actually impede learning. When code just “appears” without you understanding the underlying principles, you don’t develop debugging skills. You miss learning fundamental patterns. You can’t reason about architectural decisions, and so you struggle to maintain and evolve the code. This creates a dependency where you need to keep going back to the AI model to fix issues rather than developing the expertise to handle them yourself.
随着自主人工智能编码代理的出现,这种依赖性风险进入了一个新的维度——我将在第十章深入探讨这一主题。与目前提供代码片段建议的工具不同,这些代理代表着软件开发方式的根本性转变。在我撰写本文时,我们正见证着一些系统的早期部署,这些系统能够在极少的人工干预下独立规划、执行和迭代整个开发任务。
This dependency risk enters a new dimension with the emergence of autonomous AI coding agents—a topic I explore in depth in Chapter 10. Unlike current tools that suggest code snippets, these agents represent a fundamental shift in how software can be developed. As I write this, we’re witnessing the early deployment of systems that can independently plan, execute, and iterate on entire development tasks with minimal human oversight.
从辅助型人工智能到自主型人工智能的演变,引发了关于开发者专业知识和控制权的深刻问题。当人工智能系统能够处理从初始实现到测试和部署的完整开发流程时,技能退化的风险就会变得尤为突出。过度依赖这些智能体而忽视基础知识维护的开发者,可能会发现,当人工智能的决策偏离预期结果时,他们无法有效地进行审核、指导或干预。
This evolution from assistive to autonomous AI introduces profound questions about developer expertise and control. When an AI system can handle complete development workflows, from initial implementation through testing and deployment, the risk of skill atrophy becomes acute. Developers who rely heavily on these agents without maintaining their foundational knowledge may find themselves unable to effectively audit, guide, or intervene when the AI’s decisions diverge from intended outcomes.
当我们考虑这些自主系统如何在整个项目中做出级联决策时,挑战就变得更加复杂。每个单独的选择单独来看可能都合理,但累积效应却可能将开发引向意想不到的方向。如果团队缺乏及早识别和纠正这些方向性偏差的专业知识,就有可能在他们尚未完全理解的基础之上构建越来越复杂的系统。
The challenge compounds when we consider how these autonomous systems make cascading decisions throughout a project. Each individual choice might appear reasonable in isolation, yet the cumulative effect could steer development in unintended directions. Without the expertise to recognize and correct these trajectory shifts early, teams risk building increasingly complex systems on foundations they don’t fully understand.
正如我们稍后将深入探讨的那样,自主编码代理的出现非但没有降低软件工程基础知识的重要性,反而凸显了它的重要性。我们的人工智能工具越强大,我们就越需要保持专业知识,成为系统的架构师,而不仅仅是操作者。只有深入理解软件原理,我们才能确保这些卓越的工具增强而非削弱我们的能力。
As we’ll examine more thoroughly later, the advent of autonomous coding agents doesn’t diminish the importance of software engineering fundamentals—it amplifies it. The more powerful our AI tools become, the more critical it is that we maintain the expertise to remain architects of our systems rather than mere operators. Only through deep understanding of software principles can we ensure these remarkable tools enhance our capabilities rather than erode them.
这正逐渐成为一种模式:团队利用人工智能快速构建令人印象深刻的演示。这条快乐之路运行得非常完美。投资者和社交网络都被惊艳到了。但当真正的用户开始点击浏览时呢?问题就出现了。
It’s becoming a pattern: teams use AI to rapidly build impressive demos. The happy path works beautifully. Investors and social networks are wowed. But when real users start clicking around? That’s when things fall apart.
我亲眼目睹过:普通用户根本看不懂的错误信息、导致应用程序崩溃的极端情况、从未清理过的令人困惑的用户界面状态、完全忽略的辅助功能,以及在低端设备上的性能问题。这些并非低优先级的小bug——它们决定了软件是用户勉强容忍还是真正喜爱。
I’ve seen this firsthand: error messages that make no sense to normal users, edge cases that crash the application, confusing UI states that never got cleaned up, accessibility completely overlooked, and performance issues on slower devices. These aren’t just low-priority bugs—they’re the difference between software people tolerate and software people love.
打造真正意义上的自助式软件——用户无需联系技术支持——需要一种截然不同的思维模式,一种对精益求精的执着追求。你需要对错误信息精益求精;在低速网络连接下,使用真实的非技术用户进行测试;确保各项功能易于发现;并妥善处理每一个极端情况。这种对细节的关注(或许)无法由人工智能生成。它源于同理心、经验以及对精益求精的执着。
Creating truly self-serve software—the kind where users never need to contact support—requires a different mindset, one that’s all about the lost art of polish. You need to be obsessing over error messages; testing on slow connections and with real, nontechnical users; making features discoverable; and handling every edge case gracefully. This kind of attention to detail (perhaps) can’t be AI-generated. It comes from empathy, experience, and caring deeply about craft.
在本书第二部分深入探讨编码之前,我们需要谈谈现代开发实践以及人工智能辅助编码如何融入团队工作流程。软件开发毕竟不仅仅是编写代码——它是一个完整的流程,包括规划、协作、测试、部署和维护。而“氛围编码”并非一种孤立的新奇事物——它可以融入敏捷方法和DevOps实践中,在提升团队效率的同时,保证质量和可靠性。
Before we dive into coding in Part II of this book, we need to talk about modern development practices and how AI-assisted coding fits within a team workflow. Software development is more than writing code, after all—it’s a whole workflow that includes planning, collaboration, testing, deployment, and maintenance. And vibe coding isn’t a standalone novelty—it can be woven into agile methodologies and DevOps practices, augmenting the team’s productivity while preserving quality and reliability.
在本节中,我们将探讨团队成员如何协同使用基于氛围的编码工具而不互相干扰,如何平衡人工智能建议与人类洞察,以及持续集成/持续交付 (CI/CD) 流水线如何集成人工智能或适应人工智能生成的代码。我还会简要介绍版本控制策略等重要考量因素。
In this section, we’ll explore how team members can collectively use vibe-coding tools without stepping on each other’s toes, how to balance AI suggestions with human insight, and how continuous integration/continuous delivery (CI/CD) pipelines can incorporate AI or adapt to AI-generated code. I’ll also touch on important considerations like version-control strategies.
在观察了数十个团队之后,我发现以下三种模式在个人和团队工作流程中都始终有效:
After observing dozens of teams, here are three patterns I’ve seen work consistently in both solo and team workflows:
The AI model generates the initial code and developers then refine, refactor, and test it
Developer and AI are in constant conversation, with tight feedback loops, frequent code review, and minimal context provided
开发人员仍然编写初始代码,然后使用人工智能对其进行验证、测试和改进(见图3-2)。
Developers still write the initial code and then use AI to validate, test, and improve it (see Figure 3-2)
在本节中,我将依次带您了解每种模式,讨论工作流程和成功技巧。
In this section, I’ll walk you through each pattern in turn, discussing workflows and tips for success.
在要求 AI 模型编写任何代码之前,务必确保团队中的每个人都理解并认同模型的目标。沟通至关重要,这样开发人员就不会要求他们的 AI 助手执行冗余任务或生成相互冲突的实现。
It’s important to ensure everyone on the team is on the same page before you ask your AI model to draft any code. Communication is key so that developers don’t ask their AI assistants to do redundant tasks or generate conflicting implementations.
在每日站会(敏捷工作流程的必备环节)中,不仅要讨论你正在做什么,还要讨论是否计划在某些任务中使用人工智能。例如,两位开发人员可能正在开发不同的功能,但这两个功能都涉及到日期格式化的实用函数。如果双方都要求 AI 创建formatDate助手,最终可能会得到两个功能相似的工具。提前协调(例如,“我会生成一个我们都能使用的日期管理工具”)可以避免重复劳动。
In daily stand-ups (a staple of agile workflows), it’s worth discussing not just what you’re working on but also whether you plan to use AI for certain tasks. For example, two developers might be working on different features that both involve a utility function for date formatting. If both ask the AI to create a formatDate helper, you might end up with two similar functions. Coordinating up front (“I’ll generate a date utility we can both use”) can prevent duplication.
成功集成 AI 工具的团队通常首先会就编码标准和提示实践达成一致。例如,团队可能会确定一套统一的编码风格(代码检查规则、项目约定),甚至将这些准则输入到 AI 工具中(一些助手允许提供风格偏好或示例代码来引导输出)。正如Codacy 博客中所述,通过让 AI 熟悉团队的编码标准,可以生成更统一、更易于所有人使用的代码。在实际操作中,这意味着可以在项目 README 文件中添加一个“AI 使用技巧”部分,其中可以注明诸如“我们只使用函数式组件”或“我们更倾向于使用 Fetch API 而不是 Axios”之类的提示,以便开发人员在提示 AI 时可以参考。
Teams that successfully integrate AI tools often start by agreeing on coding standards and prompting practices. For example, the team might decide on a consistent style (linting rules, project conventions) and even feed those guidelines into their AI tools (some assistants allow providing style preferences or example code to steer outputs). As noted in Codacy’s blog, by familiarizing the AI with the team’s coding standards, you get generated code that is more uniform and easier for everyone to work with. On a practical level, this could mean having a section in your project README for “AI Usage Tips,” where you note things like “We use functional components only” or “Prefer using Fetch API over Axios,” which developers can keep in mind when prompting AI.
另一种做法是使用工具的协作功能(如果有的话)。一些人工智能辅助的集成开发环境(IDE)允许用户共享他们的人工智能会话,或者至少共享他们使用的提示。如果开发人员 A 使用某个提示对一个复杂组件进行了优化,并取得了很好的结果,那么将该提示分享给开发人员 B(例如通过问题跟踪系统或团队聊天)可以节省时间并确保一致性。
Another practice is to use your tools’ collaboration features, if available. Some AI-assisted IDEs allow users to share their AI sessions or at least the prompts they use. If Developer A got a great result with a prompt for a complex component, sharing that prompt with Developer B (perhaps via the issue tracker or a team chat) can save time and ensure consistency.
至于版本控制的使用,基本原理仍然不变,只是略有不同。在现代开发中,使用 Git(或其他版本控制系统)是必不可少的,Vibe 编码也不例外。事实上,当 AI 快速生成代码时,版本控制变得更加重要。提交就像一张安全网,可以捕获 AI 的错误;如果 AI 生成的更改破坏了某些东西,您可以回滚到之前的提交。
As for using version control, the fundamentals remain—with a twist. Using Git (or another version control system) is nonnegotiable in modern development, and that doesn’t change with vibe coding. In fact, version control becomes even more crucial when AI is generating code rapidly. Commits act as the safety net to catch AI missteps; if an AI-generated change breaks something, you can revert to a previous commit.
一种策略是在使用 AI 辅助时更频繁地提交代码。每次 AI 生成你认可的重要代码块(例如生成新功能或进行重大重构)时,都应考虑提交代码并附上清晰的说明。频繁提交可以确保,当你需要排查问题或撤销 AI 生成的部分代码时,历史记录足够详细。
One strategy is to commit more frequently when using AI assistance. Each time the AI produces a significant chunk of code (like generating a feature or doing some major refactoring) that you accept, consider making a commit with a clear message. Frequent commits ensure that if you need to bisect issues or undo a portion of AI-introduced code, the history is granular enough.
此外,尽量将不同的 AI 引入的更改分开。如果让 AI 在不同领域进行大量更改并一起提交,一旦出现问题,就很难理清头绪。例如,如果您使用代理来优化性能,并且它还调整了一些 UI 文本,请分别提交这些更改。(您的两条提交信息可能是“优化列表渲染性能 [AI 辅助]”和“更新锻炼完成消息的 UI 文本 [AI 辅助]”)。描述性的提交信息非常重要;有些团队甚至会标记大量 AI 参与的提交,以便于追溯。这并非为了追究责任,而是为了了解代码的来源——带有“[AI]”标签的提交可能提示代码审查人员,该代码需要针对特殊情况进行更彻底的审查。
Also, try to isolate different AI-introduced changes. If you let the AI make many changes across different areas and commit them all together, it’s harder to disentangle if something goes wrong. For example, if you use an agent to optimize performance and it also tweaks some UI texts, commit those separately. (Your two commit messages might be “Optimize list rendering performance [AI-assisted]” and “Update UI copy for workout completion message [AI-assisted]”). Descriptive commit messages are important; some teams even tag commits that had heavy AI involvement, just for traceability. It’s not about blame but about understanding the origin of code—a commit tagged with “[AI]” might signal to a reviewer that the code could use an extra thorough review for edge cases.
从本质上讲,团队应该将 AI 的使用视为开发对话的正常组成部分:分享经验、成功的技术,以及关于不应该做什么的警告(例如“Copilot 建议使用过时的 X 库,所以要小心”)。
Essentially, the team should treat AI usage as a normal part of the development conversation: share experiences, successful techniques, and warnings about what not to do (like “Copilot suggests using an outdated library for X, so be careful with that”).
审查和改进是这种模式的关键。开发人员应该手动审查和重构代码以提高模块化程度,添加全面的错误处理,编写详尽的测试,并在改进代码的过程中记录关键决策。下一章将详细介绍这些过程。
Review and refinement are crucial to this pattern. Developers should manually review and refactor the code for modularity, add comprehensive error handling, write thorough tests, and document key decisions as they refine the code. The next chapter goes into detail about these processes.
传统的结对编程是指两个人共用一个工作站进行协作。随着人工智能的出现,一种混合模式应运而生:一位人类开发者与人工智能助手协同工作。这种模式尤其有效,它融合了人类的直觉和机器的效率。
Traditional pair programming involves two humans collaborating at one workstation. With the advent of AI, a hybrid approach has emerged: one human developer working alongside an AI assistant. This setup can be particularly effective, offering a blend of human intuition and machine efficiency.
在人机协作模式下,开发者与人工智能交互生成代码建议,同时审查并优化输出结果。这种动态机制使开发者能够利用人工智能处理重复性任务(例如编写样板代码或生成测试用例)的速度优势,同时保持监督,确保代码质量和相关性。
In a human-AI pairing, the developer interacts with the AI to generate code suggestions while also reviewing and refining the output. This dynamic allows the human to leverage the AI’s speed in handling repetitive tasks, such as writing boilerplate code or generating test cases, while maintaining oversight to ensure code quality and relevance.
例如,在集成新库时,开发人员可以引导人工智能生成初始集成代码。然后,开发人员审查人工智能的建议,并参考官方文档来验证其准确性。这个过程不仅加快了开发速度,还有助于知识积累,因为开发人员可以深入研究人工智能的输出结果以及库的复杂细节。
For instance, when integrating a new library, a developer might prompt the AI to draft the initial integration code. The developer then reviews the AI’s suggestions, cross-referencing with official documentation to verify accuracy. This process not only accelerates development but also facilitates knowledge acquisition, as the developer engages deeply with both the AI’s output and the library’s intricacies.
Let’s compare this to traditional human-human pair programming:
Human-AI pairing offers rapid code generation and can handle mundane tasks efficiently. It’s particularly beneficial for solo developers or when team resources are limited.
人与人之间的结对编程在解决复杂问题方面表现出色,因为在这些场景中,细致入微的理解和协作式头脑风暴至关重要。它有助于培养共同责任感和对代码的集体理解。
Human-human pairing excels in complex problem-solving scenarios, where nuanced understanding and collaborative brainstorming are essential. It fosters shared ownership and collective code comprehension.
两种方法各有优点,您可以根据项目的复杂性、资源可用性和开发过程的具体目标来选择合适的方法。
Both approaches have their merits, and your choice between them can be guided by the project’s complexity, resource availability, and the specific goals of the development process.
为了最大限度地好处在进行人工智能辅助开发时,请考虑以下做法:
To maximize the benefits of AI-assisted development, consider the following practices:
这有助于保持上下文清晰,并确保人工智能的建议与当前的具体任务相关。
This helps maintain context clarity and ensures the AI’s suggestions are relevant to the specific task at hand.
提供清晰明确的指令可以提高人工智能输出的质量。
Providing clear and specific instructions enhances the quality of the AI’s output.
定期集成和测试 AI 生成的代码有助于及早发现问题并保持项目势头。
Regularly integrating and testing AI-generated code helps catch issues early and maintains project momentum.
持续评估人工智能的贡献,根据需要提供纠正或改进,以指导其学习并改进未来的建议。
Continuously assess the AI’s contributions, providing corrections or refinements as needed to guide its learning and improve future suggestions.
除了代码生成之外,人工智能还可以作为有价值的验证工具,协助进行代码审查和质量保证。人工智能工具可以分析代码,发现潜在的错误、安全漏洞以及是否符合最佳实践。例如,DeepCode 和 Snyk 等平台的人工智能代码检查器可以识别诸如缺少输入清理或不安全配置等问题,并直接在开发环境中提供可操作的洞察。Qodo 和 TestGPT 等平台可以自动生成测试用例,确保更广泛的测试覆盖范围并减少人工工作量。许多人工智能工具还可以辅助监控应用程序性能,检测可能表明潜在问题的异常情况。
Beyond code generation, AI can serve as a valuable validator, assisting in code review and quality assurance. AI tools can analyze code for potential bugs, security vulnerabilities, and adherence to best practices. For example, platforms like DeepCode and Snyk’s AI-powered code checker can identify issues such as missing input sanitization or insecure configurations, providing actionable insights directly within the development environment. Platforms such as Qodo and TestGPT can automatically generate test cases, ensuring broader coverage and reducing manual effort. And many AI tools can assist in monitoring application performance, detecting anomalies that might indicate underlying issues.
通过将人工智能验证器集成到开发工作流程中,团队可以提高代码质量,降低缺陷发生的可能性,并确保符合安全标准。这种主动验证方法可以补充人工监督,从而打造更健壮、更可靠的软件。这些工具通过处理重复性和耗时的任务来提高质量保证 (QA) 流程的效率和效果,使测试人员能够专注于 QA 中更复杂和更细致的方面。
By integrating AI validators into the development workflow, teams can enhance code quality, reduce the likelihood of defects, and ensure compliance with security standards. This proactive approach to validation complements human oversight, leading to more robust and reliable software. These tools enhance the efficiency and effectiveness of the quality assurance (QA) process by handling repetitive and time-consuming tasks, allowing human testers to focus on more complex and nuanced aspects of QA.
将人工智能融入开发流程,无论是作为结对程序员还是验证器,都能提升生产力和代码质量。通过巧妙地整合这些工具,开发者可以充分利用人类智能和人工智能的优势。
Incorporating AI into the development process, whether as a pair programmer or validator, offers opportunities to enhance productivity and code quality. By thoughtfully integrating these tools, developers can harness the strengths of both human and artificial intelligence.
为了最大限度地发挥效益在人工智能和人类质量保证能力方面,我推荐以下几项最佳实践:
To maximize the benefits of both AI and human capabilities in QA, I recommend a few best practices:
利用人工智能进行初步评估和初步扫描,以识别明显的问题。
Use AI for initial assessments and preliminary scans to identify obvious issues.
优先对关键领域进行人工审核,例如复杂功能、用户体验和人工智能局限性。
Prioritize human review for critical areas, such as complex functionalities, user experience, and AI limitations.
Foster an environment of continuous collaboration, where AI tools and human testers work in tandem, with ongoing feedback loops to improve both AI performance and human decision making.
Vibe 编码提供了前所未有的速度和创意软件开发的自由度,正是其灵活性所要求的,是确保质量一致性和团队凝聚力。人工智能辅助开发的快速、直观特性,若缺乏平衡创造性探索与工程规范的明确指导,很容易导致混乱。
While vibe coding offers unprecedented speed and creative freedom in software development, its very flexibility demands a structured approach to ensure consistent quality and team cohesion. The rapid, intuitive nature of AI-assisted development can quickly lead to chaos without clear guidelines that balance creative exploration with engineering discipline.
这些黄金法则源于众多成功将“氛围编码”融入工作流程的团队的集体经验。它们代表了来之不易的洞见,揭示了人工智能的优势所在、不足之处,以及人类判断在整个过程中不可或缺的重要性。这些原则并非限制创造力,而是构建了一个框架,使团队能够在保持生产级软件所需标准的前提下,自信地进行实验。
These golden rules emerged from collective experience across teams who have successfully integrated vibe coding into their workflows. They represent hard-won insights about where AI excels, where it stumbles, and how human judgment remains essential throughout the process. Rather than constraining creativity, these principles create a framework within which teams can confidently experiment while maintaining the standards necessary for production-ready software.
这些规则涵盖了“氛围编码”的三个关键维度:人与人工智能的交互、人工智能生成的代码与现有系统的集成,以及培养支持可持续人工智能辅助开发的团队实践。遵循这些准则,团队可以充分发挥“氛围编码”的变革力量,同时避免导致技术债务、安全漏洞或代码库难以维护的常见陷阱:
The rules address three critical dimensions of vibe coding: the interaction between human and AI, the integration of AI-generated code into existing systems, and the cultivation of team practices that support sustainable AI-assisted development. By following these guidelines, teams can harness the transformative power of vibe coding while avoiding common pitfalls that lead to technical debt, security vulnerabilities, or unmaintainable codebases:
与人工智能交互时,请清晰地阐述您的需求、任务和预期结果。精准的提示才能带来精准的结果。
Clearly articulate your requirements, tasks, and outcomes when interacting with AI. Precise prompts yield precise results.
必须始终将人工智能生成的代码与你的最初目标进行比对。在接受之前,请验证其功能、逻辑和相关性。
AI-generated code must always be checked against your original goal. Verify functionality, logic, and relevance before accepting.
将人工智能的输出结果视为需要您仔细审核的草稿。提供反馈、进行完善,并确保其质量和正确性。
Consider AI outputs as drafts that require your careful oversight. Provide feedback, refine, and ensure quality and correctness.
利用人工智能实现日常或复杂任务的自动化,但始终积极参与问题解决和决策制定。
Leverage AI to automate routine or complex tasks, but always remain actively engaged in problem solving and decision making.
在开始人工智能驱动的开发之前,请与您的团队就人工智能使用标准、代码期望和实践达成一致。
Align with your team on AI usage standards, code expectations, and practices before starting AI-driven development.
定期与团队讨论人工智能方面的经验、技术、成功案例和不足之处。将人工智能视为促进团队整体进步的又一工具。
Regularly discuss AI experiences, techniques, successes, and pitfalls with your team. Normalize AI as another tool for collective improvement.
在版本控制中明确识别和区分 AI 生成的更改,以简化审查、回滚和跟踪。
Clearly identify and separate AI-generated changes within version control to simplify reviews, rollbacks, and tracking.
通过对所有贡献进行同样严格的审查流程,保持一致的标准,从而提高代码质量和团队理解。
Maintain consistent standards by subjecting all contributions to the same rigorous review processes, enhancing code quality and team understanding.
除非你彻底理解其功能和影响,否则切勿集成人工智能生成的代码。理解对于代码的可维护性和安全性至关重要。
Never integrate AI-generated code unless you thoroughly comprehend its functionality and implications. Understanding is critical to maintainability and security.
清晰记录人工智能生成代码的原理、功能和上下文。良好的文档能够确保长期的清晰度,并减少未来的技术债务。
Clearly document the rationale, functionality, and context for AI-generated code. Good documentation ensures long-term clarity and reduces future technical debt.
编写能够生成高质量人工智能输出的文档提示。维护一个经过验证的提示库,以简化未来的交互并提高一致性。
Document prompts that lead to high-quality AI outputs. Maintain a repository of proven prompts to streamline future interactions and enhance consistency.
定期审查并改进您的人工智能开发工作流程。利用过去的经验教训,不断提升团队的方法。
Periodically review and refine your AI development workflow. Use insights from past experiences to continuously enhance your team’s approach.
遵循这些黄金法则,您的团队可以有效地利用人工智能,在保持清晰度、质量和控制力的同时提高生产力。
By adhering to these golden rules, your team can harness AI effectively, enhancing productivity while maintaining clarity, quality, and control.
“70%难题”定义了当前人工智能辅助开发的现状:这些工具擅长生成样板代码和常规功能,但在处理剩余的30%(包括边界情况、架构决策和生产就绪)时却力不从心。我们发现了两种主要的使用模式——快速构建最小可行产品(MVP)的“启动者”和将人工智能集成到日常工作流程中的“迭代者”——以及一些常见的失败模式,例如“两步倒退”反模式和“演示级陷阱”(即令人印象深刻的原型在实际压力下会失效)。
The 70% problem defines the current state of AI-assisted development: these tools excel at generating boilerplate and routine functions but struggle with the final 30% that includes edge cases, architectural decisions, and production readiness. We’ve identified two main usage patterns—bootstrappers who rapidly build MVPs, and iterators who integrate AI into daily workflows—along with common failure patterns like the “two steps back” antipattern and the “demo-quality trap” where impressive prototypes fail under real-world pressure.
三种行之有效的流程模式已经出现:AI 作为初始编写者(先生成代码,再进行完善)、AI 作为结对程序员(持续协作)以及 AI 作为验证者(对人工编写的代码进行 AI 分析)。Vibe 编码的黄金法则提供了必要的指导原则,强调清晰的沟通、彻底的验证、团队协作,以及在合并代码之前必须完全理解所有代码的必要性。
Three proven workflow patterns have emerged: AI as first drafter (generate then refine), AI as pair programmer (continuous collaboration), and AI as validator (human-written code with AI analysis). The golden rules of vibe coding provide essential guardrails, emphasizing clear communication, thorough validation, team coordination, and the nonnegotiable requirement to understand all code before merging it.
开发者应选择一种工作流程模式进行系统性的试验,并在日常实践中贯彻黄金法则。与其在代码生成方面与人工智能竞争,不如 专注于培养第四章中介绍的持久技能:系统设计、调试和架构。
Individual developers should choose one workflow pattern to experiment with systematically while implementing the golden rules in daily practice. Focus on developing the durable skills covered in Chapter 4: system design, debugging, and architecture—rather than competing with AI on code generation.
团队需要制定人工智能使用标准,创建共享的有效提示库,并将人工智能的考量融入现有的敏捷实践中。定期分享成功经验和失败教训,有助于团队避免常见陷阱,同时最大限度地发挥人工智能的优势。
Teams need to establish standards for AI usage, create shared repositories of effective prompts, and integrate AI considerations into existing agile practices. Regular knowledge sharing about successes and pitfalls will help teams avoid common traps while maximizing AI’s benefits.
随着自主人工智能编码代理的出现,人类的角色将转向架构监督和战略决策。下一章将探讨如何最大限度地发挥人类这一不可替代的贡献,帮助各级工程师与日益强大的人工智能系统建立合作伙伴关系,而非成为竞争对手。
As autonomous AI coding agents emerge, the human role will shift toward architectural oversight and strategic decision making. The next chapter explores how to maximize this irreplaceable human contribution, helping engineers at every level thrive as partners to increasingly capable AI systems rather than competitors.
1本章基于一篇最初发表在我 Substack 时事通讯上的文章。参见 Addy Osmani, “70% 问题:关于 AI 辅助编码的残酷真相”, Elevate with Addy Osmani,2024 年 12 月 4 日。
1 This chapter is based on an essay originally published on my Substack newsletter. See Addy Osmani, “The 70% Problem: Hard Truths About AI-Assisted Coding”, Elevate with Addy Osmani, December 4, 2024.
你已经见识过 Cursor、Cline、Copilot 和 Windsurf 等 AI 编码助手如何改变了软件的构建方式,承担了大部分繁琐的工作和样板代码——大约 70%。¹但是……工作的最后“30%”区分玩具解决方案和可用于生产环境的系统的关键是什么?这种差距体现在诸多难点:理解复杂的需求、构建可维护的系统架构、处理极端情况以及确保代码的正确性。换句话说,人工智能虽然可以生成代码,但在工程设计方面却常常力不从心。
You’ve seen how AI coding assistants like Cursor, Cline, Copilot, and Windsurf have transformed how software is built, shouldering much of the grunt work and boilerplate—about 70%.1 But what about that last “30%” of the job that separates a toy solution from a production-ready system? This gap includes the hard parts: understanding complex requirements, architecting maintainable systems, handling edge cases, and ensuring code correctness. In other words, while AI can generate code, it often struggles with engineering.
蒂姆·奥莱利回顾了数十年来的技术变革,提醒我们,自动化技术的每一次飞跃都改变了我们编程的方式,但并没有改变我们为什么需要熟练的程序员。我们面临的并非编程的终结,而是“我们今天所知的编程方式的终结”,这意味着开发人员的角色正在演变,而不是消失。
Tim O’Reilly, reflecting on decades of technology shifts, reminds us that each leap in automation has changed how we program but not why we need skilled programmers. We’re not facing the end of programming but rather “the end of programming as we know it today,” meaning developers’ roles are evolving, not evaporating.
如今工程师面临的挑战在于,既要充分利用人工智能的优势(前70%),又要加倍投入到剩余30%所需的持久技能和洞察力上。本文将深入探讨专家见解,指出哪些人类技能仍然至关重要。我们将探讨高级和中级开发人员应该继续利用哪些技能,以及初级开发人员必须投资哪些技能才能与人工智能协同发展。
The challenge for today’s engineers is to embrace AI for what it does best (the first 70%) while doubling down on the durable skills and insights needed for the remaining 30%. This article dives into expert insights to identify which human skills remain crucial. We’ll explore what senior and midlevel developers should continue to leverage and what junior developers must invest in to thrive alongside AI.
因此,本章的目标是为您提供切实可行的指导,以最大限度地发挥这不可替代的 30% 的价值,并为各个级别的工程师提供可操作的要点。
This chapter’s goal, then, is to offer you pragmatic guidance for maximizing the value of that irreplaceable 30%, with actionable takeaways for engineers at every level.
如果你是一名资深工程师,你应该能看到这种趋势。的人工智能编码工具可以成为您提升自身影响力的契机——前提是您能以正确的方式运用自身经验。资深开发人员通常拥有深厚的领域知识、对潜在问题的敏锐洞察力以及做出高层次技术决策的能力。
If you’re a senior engineer, you should see the advent of AI coding tools as an opportunity to amplify your impact—if you leverage your experience in the right ways. Senior developers typically possess deep domain knowledge, intuition for what could go wrong, and the ability to make high-level technical decisions.
这些优势属于人工智能无法独立处理的30%任务的一部分。本节将探讨经验丰富的开发人员如何最大限度地发挥这些优势的价值。
These strengths are part of the 30% that AI can’t handle alone. This section looks at how seasoned developers can maximize their value.
让 AI 处理代码的初稿,而您可以专注于构建解决方案架构,然后完善 AI 的输出。史蒂夫·耶格(Steve Yegge) 指出,在许多组织中,我们可能会看到一种转变,即团队只需要“高级助理”,他们负责“(a) 描述待完成的任务,也就是创建提示,以及 (b) 审核最终成果的准确性和正确性”。接受这种模式吧。作为一名高级开发人员,您可以将复杂的需求转化为有效的提示或 AI 助手规范,然后运用您的批判性思维来审查生成的每一行代码。你实际上是在和人工智能进行结对编程——它是打字快的,而你是大脑。
Let AI handle the first draft of code while you focus on architecting the solution and then refining the AI’s output. In many organizations, Steve Yegge writes that we may see a shift where teams need “only senior associates” who “(a) describe the tasks to be done; i.e., create the prompts, and (b) review the resulting work for accuracy and correctness.” Embrace that model. As a senior dev, you can translate complex requirements into effective prompts or specifications for an AI assistant, then use your critical eye to vet every line produced. You are effectively pair programming with the AI—it’s the fast typer, but you’re the brain.
在代码审查过程中保持高标准:确保代码符合组织的质量、安全性和性能基准。通过同时扮演架构师和编辑的角色,您可以避免被“繁重的审查负担”压垮。(需要注意的是:如果初级员工直接把未经处理的 AI 输出扔给您,请务必提出异议——建立一套流程,要求他们必须先验证 AI 生成的代码,这样您就不是唯一的安全保障。)
Maintain high standards during review: ensure the code meets your organization’s quality, security, and performance benchmarks. By acting as architect and editor, you prevent the “high review burden” from overwhelming you. (A cautionary note: if junior staff simply throw raw AI output over the wall to you, push back—instill a process where they must verify AI-generated work first, so you’re not the sole safety net.)
资深工程师经常主导大型项目或处理初级工程师无法独自完成的棘手重构工作。人工智能可以通过处理大量机械性变更或在您的指导下探索替代方案,极大地提升这些工作效率。Yegge 将这种工作方式称为“面向聊天的编程”(CHOP) ——“通过迭代提示改进进行编码”,其中人工智能扮演着协作者的角色。充分利用 CHOP,在你所承担的事情上更有雄心壮志。
Senior engineers often drive large projects or tackle hairy refactors that juniors can’t approach alone. AI can supercharge these efforts by handling a lot of mechanical changes or exploring alternatives under your guidance. Yegge introduced the term chat-oriented programming (CHOP) for this style of working—“coding via iterative prompt refinement,” with the AI as a collaborator. Leverage CHOP to be more ambitious in what you take on.
人工智能的辅助降低了项目是否值得投入时间的门槛,因为原本可能需要几天才能完成的工作,现在几个小时就能搞定。因此,资深开发人员可以尝试那些“如果……该多好啊?”的项目,而这些项目以前似乎总是遥不可及。
Having AI assistance lowers the bar for when a project is worth investing time in at all since what might have taken days can now be done in hours. Senior devs can thus attempt those “Wouldn’t it be nice if…?” projects that always seemed slightly out of reach.
关键在于保持主导地位:由你决定采用哪些工具或方法,并将各个部分整合为一个整体。你的经验能帮助你筛选人工智能的建议——接受合适的,拒绝不合适的。
The key is to remain the guiding mind: you decide which tools or approaches to pursue, and you integrate the pieces into a cohesive whole. Your experience allows you to sift the AI’s suggestions—accepting those that fit, rejecting those that don’t.
资深工程师的另一项关键职责是指导经验不足的团队成员有效使用人工智能以及遵循永恒的最佳实践。你可能已经积累了一些初级员工看不到的陷阱方面的宝贵经验,例如内存泄漏、差一错误和并发风险。
Another crucial role for senior engineers is to coach less-experienced team members on effective use of AI and on the timeless best practices. You likely have hard-won knowledge of pitfalls that juniors may not see, like memory leaks, off-by-one errors, and concurrency hazards.
如今,初级员工有可能通过人工智能生成代码,因此教会他们如何进行代码的自我审查和测试至关重要。要以身作则,演示如何彻底测试人工智能的贡献,并鼓励他们培养质疑和验证机器输出的文化。一些组织(甚至包括律师事务所)已经制定了相关规定:如果有人使用人工智能生成代码或撰写文章,则必须公开披露并自行验证结果,而不能仅仅指望资深同事会发现错误。
With juniors now potentially generating code via AI, it’s important to teach them how to self-review and test that code. Set an example by demonstrating how to thoroughly test AI contributions, and encourage a culture of questioning and verifying machine output. Some organizations (including even law firms) have instituted rules that if someone uses an AI to generate code or writing, they must disclose it and verify the results themselves—not just assume a senior colleague will catch mistakes.
作为一名资深工程师,你应该在团队中倡导这样的规范:我们欢迎人工智能,但严谨的工作态度至关重要。通过这种方式指导初级工程师,你可以减轻一些监督负担,并帮助他们更快地掌握那30%的核心技能。
As a senior engineer, champion such norms on your team: AI is welcome, but diligence is required. By mentoring juniors in this way, you offload some of the oversight burden and help them grow into that 30% skill set more quickly.
您丰富的经验和背景比以往任何时候都更加重要。资深开发人员通常对公司内部事物以特定方式构建的原因或行业的运作方式有着历史性的了解。这种领域知识使他们能够发现新手无法发现的人工智能错误。
Your broad experience and context are more important than ever. Senior developers often have historical knowledge of why things in the company are built a certain way or how an industry operates. This domain mastery lets you catch AI’s missteps that a newcomer wouldn’t.
持续投入,深入了解问题领域。这可能意味着要及时掌握业务需求、用户反馈或影响软件的新法规。除非你明确指示,否则人工智能不会自动考虑这些因素。将你的领域洞察力与人工智能的速度相结合,才能获得最佳结果。
Continue investing in understanding the problem domain deeply. That might mean staying up-to-date with the business’s needs, user feedback, or new regulations that affect the software. AI won’t automatically incorporate these considerations unless you tell it to. When you combine your domain insight with AI’s speed, you get the best outcomes.
此外,还要运用你的远见卓识来引导人工智能的发展。例如,如果你知道快速修复会在日后造成维护上的麻烦,你可以指示人工智能实施更可持续的解决方案。相信你多年来磨练出的直觉——如果一段代码看起来“不对劲”或好得令人难以置信,那就深入研究。十有八九,你的直觉会发现人工智能没有考虑到的问题。能够预见代码的二阶和三阶效应是资深工程师的标志;不要让人工智能的便利性削弱了这种习惯。相反,要将这种习惯应用到人工智能生成的任何代码中。
Also, use your foresight to steer AI. For instance, if you know that a quick fix will create maintenance pain down the line, you can instruct the AI to implement a more sustainable solution. Trust the instincts you’ve honed over the years—if a code snippet looks “off” or too good to be true, dig in. Nine times out of ten, your intuition has spotted something that the AI didn’t account for. Being able to foresee the second- and third-order effects of code is a hallmark of senior engineers; don’t let the convenience of AI blunt that habit. Instead, apply it to whatever the AI produces.
人工智能承担部分编码工作后,资深开发人员可以将更多精力投入到工程的人文方面:与利益相关者沟通、主持设计会议以及做出使技术与业务战略相符的判断,这些都是至关重要的。蒂姆·奥莱利等人认为,随着机械式编码变得越来越容易,价值的重心转移到决定构建什么以及如何协调复杂的系统上。
With AI shouldering some coding, senior developers can spend more energy on the human side of engineering: communicating with stakeholders, leading design meetings, and making judgment calls that align technology with business strategy. Tim O’Reilly and others suggest that as rote coding becomes easier, the value shifts to deciding what to build and how to orchestrate complex systems.
资深工程师通常是统筹全局、把握全局的人。主动承担起这个角色。积极参与架构路线图的编写、评估应该采用哪些工具(包括人工智能工具或其他工具),或者制定组织的人工智能编码规范。这些都是人工智能无法完成的任务——它们需要经验、人的判断力,而且通常还需要跨团队的共识。通过增强你的领导影响力,你可以确保自己不仅仅是代码生成器(可以被其他工具替代),而是指导团队不可或缺的技术领导者。
Senior engineers are often the ones orchestrating and seeing the big picture. Step up to that role. Volunteer to write that architecture roadmap, to evaluate which tools (AI or otherwise) to adopt, or to define your org’s AI coding guidelines. These are tasks AI can’t do—they require experience, human discretion, and, often, cross-team consensus building. By amplifying your leadership presence, you ensure that you’re not just a code generator (replaceable by another tool) but an indispensable technical leader guiding the team.
简而言之,继续发挥经验丰富的开发者的优势:高瞻远瞩,把握全局。人工智能能帮你砍伐更多树木,但最终还是需要有人来决定砍伐哪些树木,以及如何用这些木材建造稳固的房屋。你的判断力、战略思维和指导能力如今显得尤为重要。能够有效利用人工智能的高级开发者,其生产力可能远超那些不善于运用人工智能的开发者——但真正卓越的开发者,是那些能够运用自身优势来增强人工智能输出,而不是放任其自由运行的人。
In short, continue doing what seasoned developers do best: seeing the forest for the trees. AI will help you chop a lot more trees, but someone still needs to decide which trees to cut and how to build a stable house from the lumber. Your judgment, strategic thinking, and mentorship are now even more critical. A senior developer who harnesses AI effectively can be dramatically more productive than one who doesn’t—but the ones who truly excel will be those who apply their human strengths to amplify the AI’s output, not just let it run wild.
正如一位Reddit用户所说,“人工智能是编程的倍增器”,它“极大地提高了资深程序员的生产力”。这种倍增效应确实存在,但真正被倍增的是你的专业技能。保持你的专业技能精湛,并将其置于开发过程的核心。
As one Redditor observed, “AI is a programming force multiplier” that “greatly increases the productivity of senior programmers.” The multiplier effect is real, but it’s your expertise that’s being multiplied. Keep that expertise sharp and at the center of the development process.
中层工程师或许面临着最大的转型压力。过去需要花费大量时间完成的许多任务——例如实现功能、编写测试、调试简单问题——正变得越来越容易自动化。
Midlevel engineers face perhaps the most significant pressure to evolve. Many of the tasks that traditionally occupied your time—implementing features, writing tests, debugging straightforward issues—are becoming increasingly automatable.
这并非意味着过时,而是意味着提升。重点从编写代码转向构建更专业的知识,以下章节将对此进行探讨。
This doesn’t mean obsolescence; it means elevation. The focus shifts from writing code to more building specialized knowledge, which the following sections explore.
随着系统变得越来越复杂,理解和管理组件之间的边界变得至关重要。这包括 API 设计、事件模式和数据模型——所有这些都需要仔细考虑业务需求和未来的灵活性。加深对计算机科学基础知识的理解,包括深入掌握以下学科:
As systems become more complex, understanding and managing the boundaries between components becomes crucial. This includes API design, event schemas, and data models—all requiring careful consideration of business requirements and future flexibility. Deepen your computer science fundamentals, including gaining an advanced understanding of disciplines like:
数据结构和算法
Data structures and algorithms
分布式系统原理
Distributed-systems principles
数据库内部原理和查询优化
Database internals and query optimization
网络协议与安全
Network protocols and security
这些知识有助于你理解人工智能生成的代码的影响,并做出更好的架构决策。
This knowledge helps you understand the implications of AI-generated code and make better architectural decisions.
还要学会处理极端情况和模糊不清的情况。现实世界的软件开发充满了各种奇葩场景和不断变化的需求。人工智能通常默认解决一般情况,因此开发者需要主动提出“如果……会怎样?”的问题,并深入探究其中的薄弱环节。
Learn to handle edge cases and ambiguity too. Real-world software is rife with oddball scenarios and changing requirements. AI tends to solve the general case by default. It’s up to the developer to ask “What if…?” and probe for weaknesses.
耐用这里需要的技能批判性思维和前瞻性——列举各种极端情况、预测故障并在代码或设计中加以解决——都至关重要。这可能意味着要考虑空输入、网络中断、异常用户操作或与其他系统的集成等问题。
The durable skills here are critical thinking and foresight—enumerating edge cases, anticipating failures, and addressing them in code or design. This might mean thinking of null input, network outages, unusual user actions, or integration with other systems.
了解业务背景或用户环境,就能发现通用人工智能根本无法识别的极端情况。经验丰富的工程师通常会考虑这些场景。要系统地测试边界并质疑假设。专注于复杂领域,在这些领域,人类的理解仍然至关重要。通用领域包括:
Understanding the business context or the user’s environment will reveal edge cases that a generic AI simply doesn’t know about. Experienced engineers habitually consider these scenarios. Practice systematically testing boundaries and questioning assumptions. Specialize in complex domains where human understanding remains crucial. Generic domains include:
具有监管要求的金融系统
Financial systems with regulatory requirements
存在隐私问题的医疗保健系统
Healthcare systems with privacy concerns
具有严格性能要求的实时系统
Real-time systems with strict performance requirements
机器学习基础设施
Machine learning infrastructure
软件工程特定 相关领域包括前端和后端工程、移动开发、DevOps 和安全工程等等。领域专业知识能够提供当前人工智能工具所缺乏的背景信息,并帮助您更好地决定在何处以及如何应用这些工具。
Software-engineering-specific domains include frontend and backend engineering, mobile development, DevOps, and security engineering, to name a few. Domain expertise provides context that current AI tools lack and helps you make better decisions about where and how to apply them.
虽然LLM可以提供一些基本建议优化,识别 和解决系统级性能问题需要深入了解整个技术栈,从数据库查询模式到前端渲染策略。随着代码生成自动化程度的提高,了解系统在生产环境中的运行方式变得越来越重要。
While LLMs can suggest basic optimizations, identifying and resolving system-wide performance issues requires a deep understanding of the entire stack, from database query patterns to frontend rendering strategies. Understanding how systems run in production becomes more valuable as code generation becomes more automated.
重点关注以下领域:
Focus on fields like the following:
监测和可观测性
Monitoring and observability
性能分析与优化
Performance profiling and optimization
安全实践和合规性
Security practices and compliance
成本管理与优化
Cost management and optimization
借助人工智能写作 大量代码,这种能力严格审查和测试代码变得至关重要。“每个人都需要更加认真地对待代码测试和审查,”Yegge强调说。对待人工智能生成的代码,要像对待初级开发人员的成果一样:你是代码审查员,负责发现错误、安全漏洞或粗糙的实现。这意味着你需要加强单元测试、集成测试和调试方面的技能。
With AI writing lots of code, the ability to rigorously review and test that code becomes even more critical. “Everyone will need to get a lot more serious about testing and reviewing code,” Yegge emphasizes. Treat AI-generated code as you would a human junior developer’s output: you are the code reviewer responsible for catching bugs, security flaws, or sloppy implementations. This means strengthening your skills in unit testing, integration testing, and debugging.
编写好的测试是一项经久耐用的技能,它能迫使你理解规范并验证其正确性。在证明错误之前,最好假设所有功能都有效。人工智能通常会生成功能齐全但未优化的代码,直到你引导它进行迭代改进。这可能是由多种原因造成的,包括训练模型所用的训练数据未能完全体现所有最佳实践。
Writing good tests is a durable skill that forces you to understand the spec and verify correctness. It’s wise to assume nothing works until proven otherwise. AI often yields functional but unoptimized code until you guide it through iterative improvement. This can be due to a number of reasons, including that the training data coding models are trained on don’t reflect all best practices as completely as they could.
培养测试思维:验证每一条关键逻辑路径,使用静态分析或代码检查工具,如果人工智能生成的代码不符合质量标准,不要犹豫重写。即使你遵循上一章讨论的“人工智能作为验证器”模式,质量保证也不是简单地外包给人工智能的领域——这正是人类勤勉发挥作用的地方。当软件运行不符合预期时,你需要真正的解决问题的能力来诊断和修复它。人工智能可以辅助调试(例如,通过建议可能的原因),但它缺乏对应用程序运行的具体环境的真正理解。人类测试人员拥有人工智能目前所缺乏的领域特定知识和对用户期望的理解。这种洞察力在评估潜在问题的相关性和影响时至关重要。诊断复杂的错误通常需要创造性的问题解决能力和考虑各种因素的能力——这些都是人类固有的技能。评估软件行为的伦理影响,例如公平性和可访问性,则需要人类的敏感性和判断力。
Cultivate a testing mindset: verify every critical logic path, use static analysis or linters, and don’t shy away from rewriting AI-given code if it doesn’t meet your quality bar. Even if you’re following the “AI as validator” pattern discussed in the previous chapter, quality assurance is not an area to simply outsource to AI—it’s where human diligence shines. When software doesn’t work as expected, you need real problem-solving chops to diagnose and fix it. AI can assist with debugging (for example, by suggesting possible causes), but it lacks true understanding of the specific context in which your application runs. Human testers possess domain-specific knowledge and an understanding of user expectations that AI currently lacks. This insight is vital when assessing the relevance and impact of potential issues. Diagnosing complex bugs often requires creative problem solving and the ability to consider a broad range of factors—skills that are inherently human. And evaluating the ethical implications of software behavior, such as fairness and accessibility, requires human sensitivity and judgment.
能够分析复杂的错误——重现错误、找出原因、了解底层系统(操作系统、数据库、库)——是一项永恒的工程技能。这通常需要对基础知识(例如内存和状态的工作原理、并发性等)有扎实的掌握,而初级开发人员必须通过实践来学习。将 AI 作为辅助工具(它可以解释错误信息或提供修复建议),但不要盲目依赖它。在调试过程中,能够系统地排查问题并应用基本原理,是优秀开发人员的必备技能。这同时也是一个反馈循环:调试 AI 编写的代码会让你学会下次如何更好地引导 AI,或者避免某些模式。
Being able to reason through a complex bug—reproducing it, isolating the cause, understanding the underlying systems (OS, databases, libraries)—is a timeless engineering skill. This often requires a strong grasp of fundamentals (how memory and state work, concurrency, etc.) that junior developers must learn through practice. Use AI as a helper (it might explain error messages or suggest fixes), but don’t rely on it thoughtlessly. The skill to methodically troubleshoot and apply first principles when debugging sets great developers apart. It’s also a feedback loop: debugging AI-written code will teach you to prompt the AI better next time or avoid certain patterns.
软件项目不仅仅是孤立的编码任务;它们存在于用户需求、时间安排、遗留代码和团队流程等更大的背景下。人工智能本身并不具备全局观,例如项目的历史或某些决策背后的逻辑(除非你明确地将所有这些信息输入到提示中,但这通常不太现实)。人类需要具备这种背景知识。
Software projects are not just isolated coding tasks; they exist within a larger context of user needs, timelines, legacy code, and team processes. AI has no innate sense of the big picture, like your project’s history or the rationale behind certain decisions (unless you explicitly feed all that into the prompt, which is often impractical). Humans need to carry that context.
这里真正重要的技能是系统思维——理解系统中一个部分的改变如何影响其他部分,软件如何服务于业务目标,以及所有组成部分如何相互关联。这种整体视角能让你恰当地运用人工智能的输出结果。例如,如果人工智能建议了一个巧妙的捷径,但这个捷径却与监管要求或公司惯例相悖,你就能发现问题所在,因为你了解相关的背景信息。务必了解项目的背景并阅读设计文档,这样你才能培养判断哪些方案合适、哪些不合适的能力。
The durable skill here is systems thinking—understanding how a change in one part of the system might impact another, how the software serves the business objectives, and how all the moving pieces connect.2 This holistic perspective lets you use AI outputs appropriately. For example, if an AI suggests a clever shortcut that contradicts a regulatory requirement or company convention, you’ll catch it because you know the context. Make it a point to learn the background of your projects and read design docs, so you can develop your judgment about what fits and what doesn’t.
最后,还有一项元技能:学习新工具和适应变化的能力。人工智能辅助开发领域正在飞速发展。保持开放心态并学习如何有效利用人工智能新功能的工程师将始终保持领先地位——蒂姆·奥莱利 (Tim O'Reilly)指出,那些“渴望学习新技能”的开发人员将从人工智能中获得最大的生产力提升。深入学习基础知识并保持对新技术的好奇心。这种结合能够让你将人工智能作为一种工具来驾驭,而不会对其产生依赖。
Finally, a metaskill: the ability to learn new tools and adapt to change. The field of AI-assisted development is evolving rapidly. Engineers who keep an open mind and learn how to effectively use new AI features will remain ahead of the curve—Tim O’Reilly suggests that developers who are “eager to learn new skills” will see the biggest productivity boosts from AI. Invest in learning the fundamentals deeply and staying curious about new techniques. This combination enables you to harness AI as a tool without becoming dependent on it.
这需要找到平衡:利用人工智能加速自身成长,但也要偶尔进行一些不依赖人工智能的练习,以确保核心学习不被忽略(一些开发者会定期进行“人工智能戒断”,以保持其原始编码技能的敏锐度)。简而言之,要做一个不断学习的工程师——这在任何时代都是一项永不过时的技能。
It’s a balancing act: use AI to accelerate your growth, but also occasionally practice without it to ensure you’re not skipping core learning (some developers do an “AI detox” periodically to keep their raw coding skills sharp). In short, be the engineer who learns constantly—that’s a career-proof skill in any era.
翻译能力之间 随着实施时间的缩短,业务需求和技术解决方案的价值日益凸显。能够与产品经理、设计师和其他利益相关者有效沟通的工程师将变得越来越重要。以下是一些值得关注的领域:
The ability to translate between business requirements and technical solutions becomes more valuable as implementation time decreases. Engineers who can effectively communicate with product managers, designers, and other stakeholders will become increasingly valuable. Good areas of focus here include:
需求收集与分析
Requirements gathering and analysis
技术写作和文档
Technical writing and documentation
项目规划和估算
Project planning and estimation
团队领导和指导
Team leadership and mentoring
与其花费数天时间来实现新功能,中级工程师不如把这些时间用于设计能够优雅地处理规模和故障模式的强大系统。这需要对分布式系统原理、数据库内部结构和云基础设施有深入的了解——而这些领域目前 LLM 提供的价值有限。
Instead of spending days implementing a new feature, midlevel engineers might spend that time designing robust systems that gracefully handle scale and failure modes. This requires deep understanding of distributed systems principles, database internals, and cloud infrastructure—areas where LLMs currently provide limited value.
练习设计能够大规模解决现实世界问题的系统。无论代码是如何生成的,这些技能仍然很有价值,因为它们需要理解业务需求和工程权衡。
Practice designing systems that solve real-world problems at scale. These skills remain valuable regardless of how code is generated, as they require understanding business requirements and engineering trade-offs.
设计一个连贯的系统需要理解权衡取舍、约束条件以及“全局”,而不仅仅是编写几个函数。人工智能可以生成代码,但不会自动为复杂问题选择最佳架构。
Designing a coherent system requires understanding trade-offs, constraints, and the “big picture” beyond writing a few functions. AI can generate code but won’t automatically choose the best architecture for a complex problem.
整体设计——包括组件如何交互、数据如何流动、如何确保可扩展性和安全性——是需要人为洞察力的30%的一部分;这包括以下方面:
The overall design—how components interact, how data flows, how to ensure scalability and security—is part of that 30% that demands human insight; this includes the following:
资深开发人员早已精通这项技能,中级和初级开发人员也应积极培养。要从模式和原则(例如关注点分离和模块化)的角度思考问题——这些原则能够引导人工智能生成的解决方案实现可维护性。记住,稳固的架构并非偶然形成;它需要经验丰富的人来掌舵。
Senior developers have long honed this skill, and midlevel and junior devs should actively cultivate it. Think in terms of patterns and principles (like separation of concerns and modularity)—these guide an AI-generated solution toward maintainability. Remember, solid architecture doesn’t emerge by accident; it needs an experienced human hand on the wheel.
请记住,人工智能应该是您工作流程中不可或缺的一部分——而不是应该抵制的东西。将人工智能融入日常工作的实用方法包括:
Remember that AI should be an integral part of your workflow—it’s not something to resist. Practical ways to incorporate AI into your daily work include:
搭建初始代码结构
Scaffolding initial code structures
快速原型和概念验证
Quick prototypes and proof of concepts
结对编程可以加快调试和问题解决速度。
Pair programming for faster debugging and problem solving
提出优化建议和替代方案
Suggesting optimizations and alternative approaches
Handling repetitive code patterns while you focus on architecture and design decisions
一种说法正在逐渐形成。那款中级软件工程师有人认为,纯粹的工程技能会因为人工智能处理了实现细节而过时,因此应该“直接放弃”。虽然这种说法有些夸张,但关于工程以外技能(例如设计)重要性的讨论值得探讨。在2024年12月X论坛的一次典型交流中,@fchollet写道:
There’s a growing narrative that midlevel software engineers should “just quit”—that pure engineering skills will become obsolete as AI handles the implementation details. While the conclusion is overstated, the discourse about the importance of skills beyond engineering (like design) deserves examination. In a representative exchange on X in December 2024, @fchollet wrote:
我们将很快进入一个可以将测试时的计算转化为实际能力的世界——在软件历史上,边际成本将首次变得至关重要。
We’ll soon be in a world where you can turn test-time compute into competence—for the first time in the history of software, marginal cost will become critical.
@garrytan 回复道:
To which @garrytan replied:
接下来,用户体验、设计以及对工艺的真正投入将成为焦点。
UX, design, actual dedication to the craft will take center stage in this next moment.
真正做出人们想要的东西。软件和编码本身不再是门槛。真正能创造出优秀软件的是博学多才、在多个领域都展现出智慧和高效能力的人。
Actually make something people want. Software and coding won’t be the gating factor. It is the ability to be a polymath and smart/effective in many domains together that creates great software.
成功的软件开发历来需要的不仅仅是编码能力。如今的变化并非工程技术的消亡,而是纯粹实现门槛的降低。这种转变实际上让工程判断和设计思维变得更加重要,而不是不那么重要。
Successful software creation has always required more than just coding ability. What’s changing is not the death of engineering but rather the lowering of pure implementation barriers. This shift actually makes engineering judgment and design thinking more crucial, not less.
想想是什么让 Figma、Notion 或 VSCode 等应用取得成功。这不仅仅是技术上的卓越——更重要的是对用户需求、工作流程和痛点的深刻理解。这种理解源于以下几点:
Consider what makes applications like Figma, Notion, or VSCode successful. It’s not just technical excellence—it’s the deep understanding of user needs, workflows, and pain points. This understanding comes from the following:
用户体验设计思维
User experience design thinking
深厚的领域知识
Deep domain knowledge
对人类心理和行为的理解
Understanding of human psychology and behavior
系统设计需考虑性能、可靠性和可扩展性
System design that considers performance, reliability, and scalability
商业模式一致性
Business model alignment
优秀的工程师从来不仅仅是程序员。他们是问题解决者,既了解技术限制,也了解人的需求。随着人工智能工具降低实施门槛,这种整体性的理解能力变得更加宝贵。
The best engineers have always been more than just coders. They’ve been problem solvers who understand both technical constraints and human needs. As AI tools reduce the friction of implementation, this holistic understanding becomes even more valuable.
但这并不意味着每个工程师都需要成为用户体验设计师。相反,这意味着要培养更强的产品思维能力,并与设计师和产品经理建立更好的协作技巧。这意味着要更多地思考用户,了解他们的心理和行为模式,并学习如何做出支持用户体验目标的技术决策。你已经达到了技术上的精妙之处:现在,你需要做的就是密切关注用户的实际需求,从而达到平衡。
However, this doesn’t mean every engineer needs to become a UX designer. Instead, it means developing stronger product thinking abilities and building better collaboration skills with designers and product managers. It means thinking more about users, understanding their psychology and behavior patterns, and learning to make technical decisions that support user experience goals. You’re at the point of achieving technical elegance: now balance it out with close attention to practical user needs.
Tan随后发帖说:
Tan went on to post:
接下来,用户体验、设计以及对工艺的真正投入将成为焦点。
UX, design, actual dedication to the craft will take center stage in this next moment.
真正做出人们想要的东西。软件和编码本身不再是门槛。真正能创造出优秀软件的是博学多才、在多个领域都展现出智慧和高效能力的人。
Actually make something people want. Software and coding won’t be the gating factor. It is the ability to be a polymath and smart/effective in many domains together that creates great software.
未来属于那些能够弥合人类需求与技术解决方案之间差距的工程师——无论是通过培养自身更好的设计意识,还是通过与敬业的设计师进行更有效的合作。
The future belongs to engineers who can bridge the gap between human needs and technical solutions—whether that’s through developing better design sensibilities themselves or through more effective collaboration with dedicated designers.
如果你是一名初级或经验不足的开发人员,你可能会对人工智能感到既兴奋又焦虑。人工智能助手可以编写你可能不知道如何编写的代码,从而有可能加快你的学习速度。然而,一些媒体却以“初级开发人员的消亡”为题,暗示入门级编程工作岌岌可危。但与大众的普遍猜测相反,尽管人工智能正在显著改变职业生涯初期的体验,初级开发人员并没有过时。
If you’re a junior or less-experienced developer, you might feel a mix of excitement and anxiety about AI. AI assistants can write code that you might not know how to write yourself, potentially accelerating your learning. Yet there are headlines about the “death of the junior developer”, suggesting entry-level coding jobs are at risk. Contrary to popular speculation, while AI is significantly changing the early-career experience, junior developers are not obsolete.
你需要积极主动地培养技能,确保你创造的价值能够超越人工智能所能提供的范围。随着这些任务日益自动化,传统的通过实现基本的CRUD应用程序和简单功能来学习的方法将会发生变化。
You need to be proactive in developing skills that ensure you’re contributing value beyond what an AI can churn out. The traditional path of learning through implementing basic CRUD applications and simple features will evolve as these tasks become increasingly automated.
考虑一个典型的初级任务:按照现有模式实现一个新的 API 端点。以前,这可能需要一整天的编码和测试。有了人工智能的辅助,实现时间可能会缩短到一小时,但关键技能却变成了:
Consider a typical junior task: implementing a new API endpoint following existing patterns. Previously, this might have taken a day of coding and testing. With AI assistance, the implementation time might drop to an hour, but the crucial skills become:
对现有系统架构有足够的了解,以便正确地提出需求。
Understanding the existing system architecture well enough to specify the requirement correctly
审查生成的代码,以发现安全隐患和极端情况
Reviewing the generated code for security implications and edge cases
确保实施方案与现有模式保持一致
Ensuring the implementation maintains consistency with existing patterns
编写全面的测试来验证业务逻辑
Writing comprehensive tests that verify business logic
这些技能不能仅仅通过观看教程或接受人工智能提示来学习——它们需要实际操作生产系统的经验以及高级工程师的指导。
These skills can’t be learned purely through tutorial following or AI prompting—they require hands-on experience with production systems and mentorship from senior engineers.
这种演变对职业生涯初期的开发者来说既是挑战也是机遇。入门级职位的门槛可能会提高,需要更强的基础知识才能有效地审查和验证人工智能生成的代码。然而,这种转变也意味着初级工程师有可能在职业生涯早期就接触到更有趣的问题。
This evolution presents both challenges and opportunities for early-career developers. The bar for entry-level positions may rise, requiring stronger fundamental knowledge to effectively review and validate AI-generated code. However, this shift also means junior engineers can potentially tackle more interesting problems earlier in their careers.
以下是如何通过投资自己来有效弥补这30%的差距。
Here’s how to invest in yourself to handle that 30% gap effectively.
人们很容易依赖人工智能来回答每一个问题(“如何在 Python 中实现 X?”),而从未真正理解其背后的概念。 克制住这种冲动。把人工智能当作导师,而不是答案自动售货机。例如,当人工智能给出一段代码时,问问它为什么选择这种方法,或者让它逐行解释代码。
It’s tempting to lean on AI for answers to every question (“How do I do X in Python?”) and never truly absorb the underlying concepts. Resist that urge. Use AI as a tutor, not just an answer vending machine. For example, when AI gives you a piece of code, ask why it chose that approach, or have it explain the code line by line.
请确保你理解诸如此类的概念 数据结构、算法、内存管理和并发性,而不总是依赖人工智能。原因很简单:当人工智能的输出错误或不完整时,你需要建立自己的思维模型来识别并修正它。如果你不积极思考人工智能生成特定代码的原因,你实际上可能会学到更少的东西,从而阻碍你的成长。因此,要花时间阅读文档,从头开始编写小程序,并巩固你的核心知识。这些基础知识经久耐用;即使你周围的工具不断变化,它们也依然适用。
Make sure you understand concepts like data structures, algorithms, memory management, and concurrency without always deferring to AI. The reason is simple: when the AI’s output is wrong or incomplete, you need your own mental model to recognize and fix it. If you’re not actively engaging with why the AI is generating certain code, you might actually learn less, hindering your growth. So take time to read documentation, write small programs from scratch, and solidify your core knowledge. These fundamentals are durable; they’ll serve you even as the tools around you change.
要建立真正的自信,有时你必须单枪匹马。许多开发者提倡定期进行“无AI日”或限制AI辅助。这可以确保你仍然能够仅凭自身技能解决问题,这对避免技能退化至关重要。你会发现它迫使你真正思考问题的逻辑,这反过来又会让你更擅长使用人工智能(因为你可以更智能地指导它)。
To build real confidence, sometimes you have to fly solo. Many developers advocate doing an “AI-free day” or otherwise limiting AI assistance periodically. This ensures you can still solve problems with just your own skills, which is important for avoiding skill atrophy. You’ll find it forces you to truly think through a problem’s logic, which in turn makes you better at using AI (since you can direct it more intelligently).
此外,每当您在AI生成的代码中遇到错误或漏洞时,在请求AI修复之前,请务必先自行调试。通过调试器单步执行或添加打印语句来查看问题所在,您将学到更多。
Additionally, whenever you encounter a bug or error in AI-generated code, jump in and debug it yourself before asking the AI to fix it. You’ll learn much more by stepping through a debugger or adding print statements to see what’s going wrong.
将人工智能的建议视为提示,而非最终答案。随着时间的推移,解决任务中最后那些棘手的部分将提升你在人工智能难以应对的领域的技能——而这正是你价值所在。
Consider AI suggestions as hints, not final answers. Over time, tackling those last tricky bits of a task will build your skill in the very areas AI struggles—exactly what makes you valuable.
作为一名初级开发人员,你应该养成的最佳习惯之一就是为你的代码编写测试。如果你使用人工智能生成代码,这一点就更加重要了。
As a junior dev, one of the best habits you can develop is writing tests for your code. This is doubly true if you use AI to generate code.
当你从语言学习模型(LLM)获得一段代码时,不要想当然地认为它是正确的——要质疑它。编写单元测试(或使用手动测试)来检验它是否真正满足需求并能处理各种边界情况。这样做有两个好处:一是能够发现人工智能输出中的问题,二是能够训练你在信任某个实现之前先思考其预期行为。
When you get a chunk of code from an LLM, don’t assume it’s correct—challenge it. Write unit tests (or use manual tests) to see if it truly handles the requirements and edge cases. This accomplishes two things: it catches issues in the AI’s output, and it trains you to think about expected behavior before trusting an implementation.
你甚至可以利用人工智能来辅助编写测试,但测试内容由你来定义。Yegge关于认真对待测试和代码审查的建议适用于所有层级。如果你能建立起认真验证自身工作(无论是否借助人工智能)的良好声誉,资深同事就会更加信任你,你也能避免让他们觉得你只是把有问题的代码“扔”给他们。
You might even use the AI to help write tests, but you define what to test. Yegge’s advice about taking testing and code review seriously applies at all levels. If you cultivate a reputation for carefully verifying your work (AI-assisted or not), senior colleagues will trust you more, and you’ll avoid the scenario where they feel you’re just “dumping” questionable code on them.
实际上,应该把测试视为开发过程中不可或缺的一部分,而不是事后才考虑的。学习如何使用测试框架,如何进行探索性手动测试,以及如何系统地重现 bug。这些技能不仅能让你更好地完成那 30% 的工作,还能加速你对代码真正工作原理的理解。
In practical terms, start treating testing as an integral part of development, not an afterthought. Learn how to use testing frameworks, how to do exploratory manual testing, and how to systematically reproduce bugs. These skills not only make you better at the 30% work, but they also accelerate your understanding of how the code really works.
记住:如果你发现了人工智能引入的漏洞,你就做到了人工智能做不到的事情——这就是附加价值。
Remember: if you catch a bug that the AI introduced, you just did something the AI couldn’t—that’s added value.
初级开发人员往往专注于“让程序运行起来”。但在人工智能时代,获得一个基本的可运行版本很容易——人工智能可以做到这一点。更难的部分(也是你应该关注的部分)是编写可读、可维护和简洁的代码。
Junior devs often focus on “getting it to work.” But in the AI era, getting a basic working version is easy—the AI can do that. The harder part (and what you should focus on) is making code that’s readable, maintainable, and clean.
开始培养对良好代码结构和风格的敏锐眼光。将人工智能的输出与你所知的最佳实践进行比较;如果人工智能代码杂乱无章或过于复杂,主动进行重构。例如,如果语言学习模型(LLM)给出的函数长达 50 行,功能过多,你可以将其拆分成更小的函数。如果变量名不明确,请重命名。
Start developing an eye for good code structure and style. Compare the AI’s output with best practices you know of; if the AI code is messy or overly complex, take the initiative to refactor it. For instance, if an LLM gives you a 50-line function that does too many things, you can split it into smaller functions. If variable names are unclear, rename them.
本质上,你可以假装自己在审查同事的代码,然后像同事写的那样改进AI的代码。这能帮助你内化优秀的设计原则。随着时间的推移,你会开始引导AI以更简洁的方式编写代码(因为你会明确指定你想要的代码风格)。软件维护人员(通常是几个月甚至几年后才开始维护的)会感谢你,而你也会证明你的思考不仅仅局限于“让它运行起来”——你拥有工程师的思维。保持代码的可维护性正是那30%由人主导的部分,所以从你职业生涯的开始就应该把它作为你的关注点。
Essentially, pretend you’re reviewing a peer’s code, and improve the AI’s code as if a peer wrote it. This will help you internalize good design principles. Over time, you’ll start prompting the AI in ways that yield cleaner code to begin with (because you’ll specify the style you want). Software maintainers (often working months or years later) will thank you, and you’ll prove that you’re thinking beyond just “make it run”—you’re thinking like an engineer. Keeping things maintainable is exactly in that human-driven 30%, so make it your concern from the start of your career.
不可否认,“快速工程”(即有效与人工智能工具交互的技能)非常有用。作为一名初级开发者,你绝对应该学习如何向人工智能提出问题,如何为其提供恰当的上下文,以及如何迭代提示以改进输出(本书第二章是一个很好的起点)。这些都是能让你脱颖而出的新技能(许多经验丰富的开发者也仍在摸索中!)。然而,请记住,良好的提示往往是理解问题的体现。如果你发现无法让人工智能执行你想要的操作,那可能是因为你首先需要理清自己的理解。把这当作一个信号。
There’s no denying that “prompt engineering”—the skill of interacting with AI tools effectively—is useful. As a junior dev, you should absolutely learn how to phrase questions to AI, how to give it proper context, and how to iterate on prompts to improve the output (Chapter 2 of this book is a good place to start). These are new skills that can set you apart (many experienced devs are still figuring this out too!). However, remember that prompting well is often a proxy for understanding the problem well. If you find you can’t get the AI to do what you want, it might be because you need to clarify your own understanding first. Use that as a signal.
一种策略是,在让AI执行解决方案之前,先用通俗易懂的语言自己概述一下。此外,还可以尝试不同的AI工具(例如Copilot、Claude等),了解它们的优势和劣势。你越熟悉这些助手,工作效率就越高——但切勿将它们的输出视为绝对正确。把AI想象成一个功能强大的Stack Overflow:它是辅助工具,而非权威。
One strategy is to outline a solution in plain English yourself before asking the AI to implement it. Also, experiment with different AI tools (Copilot, Claude, etc.) to see their strengths and weaknesses. The more fluent you are with these assistants, the more productive you can be—but never treat their output as infallible. Think of AI like a super-charged Stack Overflow: an aid, not an authority.
你甚至可以利用人工智能构建一些小型个人项目来挑战自己的极限(“我能借助人工智能构建一个简单的Web应用程序吗?”)。这样做可以教会你如何将人工智能融入开发工作流程,这对团队来说是一项非常宝贵的技能。但正如前面提到的,也要兼顾一些没有网络的工作时间。
You might even build small personal projects using AI to push your limits (“Can I build a simple web app with AI’s help?”). Doing so will teach you how to integrate AI into a development workflow, which is a great skill to bring into a team. Just balance it with periods of working without the net, as mentioned earlier.
最后,一项能够加速你成长的持久技能是寻求反馈并向他人学习的能力。如果你忽略人工智能的建议,它不会生气,但你的队友和导师对你的发展至关重要——尤其是在软技能、领导力、沟通和应对办公室政治方面。
Lastly, one durable skill that will accelerate your growth is the ability to seek out feedback and learn from others. An AI won’t get offended if you ignore its advice, but your human teammates and mentors are invaluable for your development—especially when it comes to soft skills, leadership, communication, and navigating office politics.
不要犹豫,向资深开发人员询问他们为何更倾向于某种解决方案,尤其是在该方案与人工智能的建议不同时。与经验更丰富的同事讨论设计决策和权衡取舍——这些对话能揭示资深工程师的思维方式,对你来说弥足珍贵。在代码审查中,要格外重视针对人工智能编写代码的评论。如果审查者指出“此函数不是线程安全的”或“这种方法存在扩展性问题”,请务必花时间理解问题的根源。这些正是人工智能可能忽略的问题,而你需要学会发现它们。随着时间的推移,你会逐渐建立起一份考虑因素的思维清单。
Don’t hesitate to ask a senior developer why they prefer one solution over another, especially if it differs from what an AI suggested. Discuss design decisions and trade-offs with more experienced colleagues—these conversations reveal how seasoned engineers think, and that’s gold for you. In code reviews, be extra receptive to comments about your AI-written code. If a reviewer points out that “this function isn’t thread-safe” or “this approach will have scaling issues,” take the time to understand the root issue. These are exactly the kinds of things an AI might miss, and you want to learn to catch them. Over time, you’ll build a mental checklist of considerations.
此外,寻找结对编程的机会(即使是远程的)。或许你可以和一位在工作流程中使用人工智能的资深工程师结对学习——你会观察他们如何引导人工智能,以及如何纠正它。但更重要的是,你会学习他们如何沟通、主持讨论以及处理微妙的团队关系。乐于接受反馈并积极寻求指导,将帮助你从执行人工智能可以完成的任务,成长为能够胜任只有人类才能完成的高价值任务的专家。从某种意义上说,你是在尽可能高效地获取通常需要经验积累的智慧。这会让你不仅仅是房间里众多程序员中的一员——你会成为团队渴望留住并提拔的那种工程师。
Additionally, find opportunities to pair program (even if remotely). Perhaps you can “pair” with a senior who uses AI in their workflow—you’ll observe how they prompt the AI and how they correct it. But even more important, you’ll see how they communicate, lead discussions, and handle delicate team dynamics. Being open to feedback and actively asking for guidance will help you mature from doing tasks that an AI could do to performing the high-value tasks that only humans can do. In a sense, you’re trying to acquire the wisdom that usually comes with experience, as efficiently as you can. That makes you more than just another coder in the room—it makes you the kind of engineer teams are eager to keep and promote.
软件开发是一项团队运动。人工智能不会参加会议(谢天谢地)——人类仍然需要与其他人交谈,以明确需求、讨论权衡取舍并协调工作。强大的沟通能力依然至关重要。要练习提出好问题,并清晰地描述问题(无论是对同事还是对人工智能)。
Building software is a team sport. AI doesn’t attend meetings (thank goodness)—humans still must talk to other humans to clarify requirements, discuss trade-offs, and coordinate work. Strong communication skills are as valuable as ever. Practice asking good questions and describing problems clearly (both to colleagues and to AI).
有趣的是,提示人工智能本身就是一种形式沟通需要你准确地表达你的想法。这与一项核心工程技能——需求分析——密切相关。3如果你能提出清晰的提示或规范,就意味着你已经认真思考过这个问题。
Interestingly, prompting an AI is itself a form of communication; it requires you to precisely express what you want. This overlaps with a core engineering skill: requirements analysis.3 If you can formulate a clear prompt or spec, it means you’ve thought through the problem.
此外,分享知识积累、文档编写和代码审查等协作技能是人工智能无法取代的。未来,随着开发者与人工智能“协同工作”,团队中人与人之间的协作——确保解决的是正确的问题——仍然至关重要。一个新兴趋势是,开发者可能会更加专注于高层设计讨论(通常会邀请人工智能参与)和任务协调,本质上扮演着指挥者的角色。沟通和领导能力将使你在这个指挥岗位上如鱼得水。
Additionally, sharing knowledge, writing documentation, and reviewing others’ code are collaborative skills that AI cannot replace. In the future, as developers work “with” AI, the human-to-human collaboration in a team—making sure the right problems are being solved—stays vital. One emerging trend is that developers may focus more on high-level design discussions (often with AI as a participant) and on coordinating tasks, essentially taking on more of a conductor role. Communication and leadership skills will serve you well in that conductor’s seat.
值得注意的是,人工智能时代年轻员工的思维方式需要转变:你需要从仅仅接受解决方案转变为创造理解。过去,你可能需要费力地研读文档才能最终编写出一个功能;现在,人工智能可以直接为你提供解决方案。如果你只是照搬照抄(复制粘贴然后继续做其他事),那么你并没有获得多少进步。
It’s worth noting a mindset shift for juniors in the AI era: you need to move from just consuming solutions to creating understanding. In the past, you might have struggled through documentation to eventually write a feature; now an AI can hand you a solution on a platter. If you simply consume it (copy-paste and move on), you haven’t grown much.
相反,应该将人工智能给出的每个解决方案都视为学习案例。深入剖析它,进行实验,并思考自己是如何得出相同结论的。将人工智能的输出视为互动式学习材料,而不是所有问题的最终答案,才能确保你——作为人类——不断提升自身能力。这样一来,人工智能不仅不会取代你的成长,反而会加速你的成长。
Instead, use each AI-given solution as a learning case. Dissect it, experiment with it, and consider how you might have arrived at it yourself. By treating AI outputs not as answers to end all questions but as interactive learning material, you ensure that you—the human—are continuously leveling up. This way, rather than replacing your growth, AI accelerates it.
许多专家认为,人工智能虽然可能减少对大量初级“程序员”的需求,但也提高了初级开发人员的标准。他们的角色正在转变,需要能够高效地与人工智能协作,并快速提升自身价值链的人才。如果你能养成本节讨论的习惯,你就能脱颖而出,成为一名优秀的初级开发人员。你不仅能提供人工智能所能提供的功能(任何公司都可以通过订阅获得这些功能),还能带来洞察力、可靠性和持续改进——这些都是未来高级开发人员的特质。
Many experts believe that while AI might reduce the need for large teams of junior “coder-grinders,” it also raises the bar for what it means to be a junior developer. The role is shifting to someone who can work effectively with AI and quickly climb the value chain. If you adopt the habits discussed in this section, you’ll distinguish yourself as a junior developer who doesn’t just bring what an AI could bring (any company can get that via a subscription) but who brings insight, reliability, and continuous improvement—traits of a future senior developer.
为了蓬勃发展在人工智能增强的发展世界各地的工程师都应该加倍重视人工智能(目前)还无法复制的持久技能和实践。无论我们的工具变得多么先进,这些能力仍然至关重要。尤其要关注以下几个方面:
To thrive in an AI-enhanced development world, engineers at all levels should double down on the enduring skills and practices that AI cannot (yet) replicate. These capabilities will remain crucial no matter how advanced our tools become. In particular, focus on these areas:
实践系统思维并保持对全局的理解
Practicing systems thinking and maintaining a contextual understanding of the big picture
磨练批判性思维、问题解决和预见能力
Honing your skills in critical thinking, problem solving, and foresight
在专业领域积累专业知识
Building expertise in specialized domains
代码审查、测试、调试和质量保证
Reviewing code, testing, debugging, and quality assurance
提升你的沟通和协作能力
Improving your communication and collaboration skills
适应变化
Adapting to change
持续学习,夯实基础,同时掌握新技能并更新知识。
Continuously learning, keeping your fundamentals strong while gaining new skills and updating your knowledge
利用人工智能
Using AI
这些技能构成了人类在软件工程领域的优势。它们经久耐用,不会随着下一个框架或工具的更新而失效;相反,人工智能的兴起反而凸显了它们的重要性。西蒙·威利森认为,人工智能的辅助实际上提升了而非降低了强大的编程技能的价值,因为拥有专业知识的人能够更有效地利用这些工具。
These skills form the human advantage in software engineering. They are durable because they don’t expire with the next framework or tooling change; if anything, AI’s rise makes them more pronounced. Simon Willison has argued that AI assistance actually makes strong programming skills more valuable, not less, because those with expertise can leverage the tools to far greater effect.
一台强大的机器,如果落入不熟练的人手中,可能会造成危险或浪费;但如果落入能干的人手中,则能带来变革。在人工智能时代,经验丰富的工程师就像一位技艺精湛的飞行员,配备了先进的副驾驶:旅程可以更快更远,但飞行员仍然必须应对风暴,确保安全着陆。
A powerful machine in unskilled hands can be dangerous or wasted, but in capable hands it’s transformative. In the AI era, an experienced engineer is like a seasoned pilot with a new advanced copilot: the journey can go faster and farther, but the pilot must still navigate the storms and ensure a safe landing.
软件工程一直以来都是这是一个持续变革的领域——从汇编语言到高级编程,从本地服务器到云端,再到如今从手动编码到人工智能辅助开发。每一次飞跃都实现了编程某些方面的自动化,但每一次,开发者们都不得不适应,并发现更多的工作要做。在回应蒂姆·奥莱利(Tim O'Reilly)的一篇文章时,一位HN评论者指出,过去的创新“几乎总是给开发者带来更多的工作、更多的发展和更多的机遇”。人工智能的兴起也不例外。它非但没有让开发者变得无关紧要,反而重塑了成功所需的技能组合。原本枯燥乏味的70%的编码工作正在变得更容易;而充满挑战的30%则在我们价值的构成中占据了越来越重要的地位。
Software engineering has always been a field of continuous change—from assembly language to high-level programming, from on-prem servers to the cloud, and now from manual coding to AI-assisted development. Each leap has automated some aspect of programming, yet each time, developers have adapted and found even more to do. In response to a Tim O’Reilly note, one HN commenter remarked that past innovations “almost always resulted in more work, more growth, more opportunities” for developers. The rise of AI is no different. Rather than making developers irrelevant, it is reshaping the skill set needed to succeed. The mundane 70% of coding is getting easier; the challenging 30% becomes an even larger part of our value.
为了最大限度地发挥人类的30%优势,应专注于那些永恒的工程技能:深入理解问题、设计简洁的解决方案、仔细审查代码质量,以及考虑用户和应用场景。经验丰富的程序员能从人工智能中获得更多收益,因为他们知道如何引导人工智能,以及在人工智能出现故障时该如何应对。将这些技能与人工智能工具相结合的人,其表现将优于那些只掌握其中一项技能的人。事实上,专家们逐渐达成共识,认为人工智能是熟练者的工具:“法学硕士是为高级用户打造的强大工具。” 这意味着我们每个人都有责任成为“高级用户”——培养能够有效运用这些新工具的专业技能。
To maximize that human 30%, focus on the timeless engineering skills: understanding problems deeply, designing clean solutions, scrutinizing code for quality, and considering the users and context. Experienced programmers are gaining more from AI because they know how to guide it and what to do when it falters. Those who combine these skills with AI tools will outperform those who have only one or the other. In fact, the consensus emerging among experts is that AI is a tool for the skilled: that “LLMs are power tools meant for power users.” This means the onus is on each of us to become that “power user”—to cultivate the expertise that lets us wield these new tools effectively.
归根结底,软件工程的精髓远不止于编写能运行的代码。它更在于编写在真实环境中、经受时间考验、并能适应不断变化的需求下都能良好运行的代码。如今的人工智能模型可以辅助代码编写,但尚无法确保代码在所有这些方面都表现良好。这正是开发人员的职责所在。
Ultimately, the craft of software engineering is more than writing code that works. It’s about writing code that works well—in a real-world environment, over time, and under evolving requirements. Today’s AI models can assist with writing code but cannot yet ensure the code works well in all those dimensions. That’s the developer’s job.
通过强化上述技能,资深开发人员可以继续引领创新,中级开发人员可以深化专业知识,初级开发人员可以加速迈向精通之路。人工智能将处理越来越多的日常工作,但您的创造力、直觉和周密的工程设计将把原始输出转化为真正有价值的成果。人工智能是一个强大的工具,但关键在于我们如何使用它。良好的工程实践、人类的判断力和学习意愿仍然至关重要。
By doubling down on the skills just outlined, senior developers can continue to lead and innovate, midlevel developers can deepen their expertise, and junior developers can accelerate their journey to mastery. AI will handle more and more of the routine, but your creativity, intuition, and thoughtful engineering will turn that raw output into something truly valuable. AI is a powerful tool, but it’s all about how we use it. Good engineering practices, human judgment, and a willingness to learn will remain essential.
实际上,无论你是与“热情初级”的人工智能结对编程,让它帮你编写函数,还是审查满是人工智能生成代码的差异文件,都不要忘记运用你独特的人类视角。问问自己:这是否解决了正确的问题?其他人能否理解和维护这段代码?存在哪些风险和极端情况?这些问题是你的责任。编程的未来的确会减少手动输入每个分号,更多地依赖指导和规划——但这仍然需要有智慧的开发者掌舵,确保一切顺利进行。
In practical terms, whether you are pair programming with an “eager junior” AI that writes your functions or reviewing a diff full of AI-generated code, never forget to apply your uniquely human lens. Ask, Does this solve the right problem? Will others be able to understand and maintain this? What are the risks and edge cases? Those questions are your responsibility. The future of programming will indeed involve less typing every semicolon by hand and more directing and curating—but it will still require developers at the helm who have the wisdom to do it right.
归根结底,优秀的软件工程始终在于解决问题,而不仅仅是编写代码。人工智能并不会改变这一点:它只是挑战我们,促使我们将解决问题的能力提升到一个新的水平。接受这一挑战,你将在这个行业的新篇章中蓬勃发展。
In the end, great software engineering has always been about problem solving, not just code slinging. AI doesn’t change that: it simply challenges us to elevate our problem solving to the next level. Embrace that challenge, and you’ll thrive in this new chapter of our industry.
1本章基于我最初发表在我的 Substack 时事通讯上的两篇文章:Addy Osmani, “超越 70%:最大限度地发挥人工智能辅助编码中 30% 的人类作用”, Addy Osmani 的《Elevate》杂志,2025 年 3 月 13 日;以及 Addy Osmani, “为你的软件工程职业生涯保驾护航”, Addy Osmani 的《Elevate》杂志,2024 年 12 月 23 日。
1 This chapter is based on two essays I first published on my Substack newsletter: Addy Osmani, “Beyond the 70%: Maximizing the Human 30% of AI-Assisted Coding”, Elevate with Addy Osmani, March 13, 2025; and Addy Osmani, “Future-Proofing Your Software Engineering Career”, Elevate with Addy Osmani, December 23, 2024.
2要了解更多关于系统思维的内容,请参阅 Donella H. Meadows 的《系统思维:入门》(第 2 版,Rizzoli 出版社,2008 年)和 Peter M. Senge 的《第五项修炼:学习型组织的艺术与实践》(Crown 出版社,2010 年)。
2 To learn more about systems thinking, check out Donella H. Meadows, Thinking in Systems: A Primer, 2nd edition (Rizzoli, 2008); and Peter M. Senge, The Fifth Discipline: The Art and Practice of the Learning Organization (Crown, 2010).
3有关此主题的更多信息,请参阅 Mark Richards 和 Neal Ford 合著的《软件架构基础》第 2 版(O'Reilly,2025 年);以及 Mark Richards、Neal Ford 和 Raju Gandhi 合著的《Head First 软件架构》(O'Reilly,2024 年)。
3 For more on this topic, see Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd edition (O’Reilly, 2025); and Mark Richards, Neal Ford, and Raju Gandhi, Head First Software Architecture (O’Reilly, 2024).
你已经学会了如何引导人工智能生成代码,并且到目前为止,你可能已经使用这些技术编写了一些代码。现在进入关键阶段:确保代码正确、安全且易于维护。
You’ve learned how to prompt an AI to generate code, and by this point you’ve likely produced some code using these techniques. Now comes a critical phase: making sure that code is correct, safe, and maintainable.
作为开发者,你不能直接把AI的输出结果拿来就草草了事。你需要审查、测试,并尽可能地改进它,然后将其集成到你的代码库中。本章重点讲解如何理解AI的输出结果,如何迭代地编辑和调试,以及如何将代码完全纳入你的项目管理。
As a developer, you can’t just take the AI’s output and blithely ship it. You need to review it, test it, possibly improve it, and integrate it with the rest of your codebase. This chapter focuses on how to understand what the AI gave you, iteratively edit and debug it, and fully take ownership of the code as part of your project.
本章内容包括:
This chapter covers:
根据你的最初意图来解读人工智能的代码
Interpreting the AI’s code in terms of your original intent
“多数人解决方案”现象,或者说为什么人工智能生成的代码通常看起来像一个常见的解决方案。
The “majority solution” phenomenon, or why AI-generated code often looks like a common solution
用于审查代码清晰度和潜在问题的技巧
Techniques to review code for clarity and potential issues
当人工智能编写的代码运行不符合预期时,如何进行调试
Debugging AI-written code when it doesn’t work as expected
为了提高代码风格或效率而重构代码。
Refactoring the code for style or efficiency
编写测试来验证代码的行为
Writing tests to validate the code’s behavior
掌握这些技能后,您将能够自信地将人工智能技术融入到您的项目中。
By mastering these skills, you’ll be able to integrate AI contributions into your projects with confidence.
当你拿到人工智能的代码后,第一步应该是进行比较。按照你的意图(你给出的提示)。代码是否满足您提出的要求?有时,人工智能可能会略有误解,或者只部分实现您的要求。
When you get the AI’s code, your first step should be to compare it to your intent (the prompt you gave). Does the code fulfill the requirements you set out? Sometimes the AI might slightly misinterpret or only partially implement what you asked.
仔细阅读代码。在脑海中或纸上逐行推导一遍:
Read through the code carefully. Step through it in your mind or on paper:
跟踪它对典型输入的处理过程。
Trace what it does for a typical input.
如果你的提示包含多个部分(“执行 X 和 Y”),请验证 AI 是否已全部执行。
If your prompt had multiple parts (“do X and Y”), verify that the AI has done them all.
确保人工智能没有添加你没有要求的功能——有时它会添加一些它“认为”有用的额外功能,例如添加日志记录或参数,这可能没问题,也可能没问题。
Ensure that the AI didn’t add functionality you didn’t ask for—sometimes it will add an extra feature it “thinks” is useful, like adding logging or a parameter, which could be OK or not.
就像对待同事的代码一样,如果有什么不清楚的地方,就记下来。仔细查找一下,或许能找到它存在的合理原因。如果找不到,就去询问原因,或者考虑把它删除。
Just as you would with a colleague’s code, if something is unclear, note it. If you look for a good reason for it to be there, you might find one. If you don’t, query it or consider removing it.
例如,如果您要求检查质数,而 AI 代码还为每个数字打印类似“正在检查 7…”的信息,这可能是您发出指令的方式造成的,也可能是其训练数据中的一种模式(某些教程代码会打印进度)。如果您不希望出现这种情况,请计划将其移除,或者指示 AI 将其移除。
For example, if you ask for a prime-number checker and the AI code also prints something like “Checking 7…” for each number, that may be an artifact of how you prompted it or a pattern from its training data (some tutorial code prints its progress). If you don’t want that, plan to remove it or prompt the AI to remove it.
还要确保特殊情况也能按预期处理。如果你的预期是让它能够处理空输入,它做到了吗?如果输入可以是None空值或负值,人工智能是否考虑过这种情况?
Also make sure the edge cases are handled as you expect. If you intended it to handle empty input, does it? If the input could be None or negative, did the AI consider that?
如果你的提示信息存在歧义,导致人工智能需要自行选择解释,请找出歧义发生的位置。例如,你可能没有指定输出格式,导致它选择打印结果而不是返回结果。现在,你需要决定是接受这种结果还是修改代码。
If something about your prompt was ambiguous and the AI had to choose an interpretation, identify where that happened. Perhaps you didn’t specify an output format, and it chose to print results instead of returning them. Now you have to decide if you want to accept that or modify the code.
理解阶段至关重要,千万不要跳过。即使你打算测试代码,通过阅读来理解代码也很重要,因为测试可能无法覆盖所有内容(而且对于一些显而易见的内容,阅读速度更快)。
This understanding phase is crucial; don’t skip it. Even if you’re going to test the code, understanding it by reading is important because tests might not cover everything (and reading is faster for some obvious things).
最后,考虑一下人工智能的假设。人工智能通常会采用“多数派”或最常见的解释(这就引出了下一节)。
Last, consider the AI’s assumptions. AI often goes for the “majority” or most common interpretation (which leads us to the next section).
使用大量代码训练的 AI 模型通常会产生在训练数据中最具代表性的解决方案(或最简单的适用解决方案)。我称之为多数人解决方案效应。在一般情况下,这种说法是正确的,但它可能并不适用于你的具体情况。
AI models trained on lots of code will often produce the solution that’s most represented in that training data (or the simplest solution that fits). I call this the majority solution effect. It’s correct in general cases, but it might not be the best for your specific situation.
例如,如果你在没有提供更多上下文的情况下要求使用搜索算法,人工智能可能会输出基本的线性搜索,因为这简单易懂且很常见。也许你实际上需要的是二分搜索,但人工智能并不知道效率至关重要,因为你没有明确说明。线性搜索适用于许多中等复杂程度的情况,但如果性能是关键,它就无法胜任了。
For example, if you ask for a search algorithm without further context, the AI might output a basic linear search, because that’s straightforward and common. Maybe you actually needed a binary search, but the AI didn’t know that efficiency was critical, because you didn’t say so. Linear search works for many moderate cases but not if performance is key.
同样,人工智能可能会使用全局变量,因为很多简单的示例都是这样做的,但这在你的项目中可能并不可接受。
Similarly, the AI might use a global variable because many simple examples do, but perhaps in your project, that’s not acceptable practice.
请注意,人工智能的解决方案可能针对通用场景进行了优化。作为人类开发者,您拥有人工智能所缺乏的对上下文的洞察力。
Be mindful that the AI’s solution might optimize for a generic scenario. As a human developer, you have insight into context that the AI lacks.
为了解决这个问题:
To address this:
找出代码中的假设。如果代码假设列表已排序或输入有效,那么这个假设是否合理?你是否明确地说明了这一点?如果没有,或许应该添加一个检查。
Identify assumptions in the code. If it assumes a list is sorted or an input is valid, was that assumption OK? Did you specify it? If not, maybe it should have included a check.
考虑其他方案:如果您知道多种解决问题的方法(例如不同的算法),人工智能是否选择了其中一种?它是否是您想要的方案?如果不是,您可以提示它选择其他方案,或者直接更改它。
Consider alternatives: If you know multiple ways to solve the problem (like different algorithms), did the AI pick one? Is it the one you want? If not, you can prompt for the alternative or just change it.
如果 AI 代码在“常规”情况下运行良好,但在您关注的特殊情况下却无法正常工作,那就需要进行修复。例如,它可能没有考虑到某些数学运算中的整数溢出问题。在许多训练示例中,这可能并未涉及,但在您的实际应用中,这可能至关重要。
If the AI code works for the “usual” case but not for edge conditions that matter to you, that’s something to fix. For instance, maybe it didn’t consider integer overflow in some math. In many training examples, that might not have been addressed, but in your context, it could be important.
了解人工智能倾向于通用解决方案,将有助于你更好地审查其代码。它并非魔法或量身定制,而是一种基于充分信息的解决方案推测。而定制化则是你的工作。
Understanding that the AI tends toward generic solutions will make you better at reviewing its code. It’s not magic or tailor-made; it’s a very educated guess at a solution. The tailoring is your job.
AI-generated code often has some telltale patterns. It might:
Include more comments than usual or oddly phrased comments (since it learned from tutorial code, which tends to be heavily commented)
始终使用某些变量名(例如循环中的 i、j、k)。
Use certain variable names consistently (like i, j, k for loops)
Lay out code in a somewhat verbose style (to cover general cases)
检查这些内容,并考虑它们是否符合您项目的风格。代码功能上可能没问题,但需要进行可读性检查。在那次传球中,你可能需要:
Check for these and consider whether they match your project’s style. The code might be functionally fine but need a readability pass. In that pass, you may want to:
Rename variables to be more descriptive or consistent with your codebase.
删除或完善注释。如果注释的内容像# check if number is prime上面那样不言自明if,您可以将其删除。但如果注释解释了复杂的逻辑,那就很好——保留或改进它。
Remove or refine comments. If it added a comment like # check if number is prime above a self-explanatory if statement, you could remove that. But if it has a comment explaining a complex bit of logic, that’s good—keep or improve it.
运行代码以确保格式一致使用代码检查工具或格式化工具(例如 Python 的 Black 或gofmtGo 的 Black)来匹配你想要的间距和括号样式。
Ensure consistent formatting by running the code through a linter or formatter (like Black for Python or gofmt for Go) to match the spacing and bracket styles you want.
还要注意任何不寻常的结构。AI是否定义了多个类或函数,而你预期只有一个?有时,AI可能会将问题拆分成多个函数,因为训练示例中就是这样做的。如果这过于复杂,你可以将它们内联(反之亦然)。代码是否过于精巧或过于简单?AI有时会生成非常直接的解决方案,或者偶尔会生成一个巧妙的单行代码。这是否符合团队的偏好?如果不符合,请进行相应的调整。
Also look for any unusual structure. Did the AI define multiple classes or functions when you expected one? Sometimes it might break a problem into multiple functions because that’s how a training example did it. If that’s overkill, you can inline them (or vice versa). Is the code too clever or too naive? AI sometimes produces a very straightforward solution or, occasionally, a fancy one-liner. Does that align with your team’s preferences? If not, adjust accordingly.
其他需要注意的潜在问题包括:
Other potential issues to watch out for include:
Yes, AI can make those, too. For example, loop boundaries can be tricky. If you have time, mentally test a simple case through the loop.
Does the code assume that a file opens successfully or that all input is in the correct format? Add error handling if it’s needed.
也许人工智能正在对大型数据集使用内部循环进行成员资格检查,尽管存在更好的方法,例如使用集合。人工智能的解决方案或许正确,但并非最优解。
Maybe the AI is using an inner loop on a large dataset for membership checks, even though a better approach exists, like using a set. The AI solution might be correct but not optimal.
如果代码使用了库,请确保它是您想要使用的库(并且它是可用的)。有时它可能会使用numpy某种函数来进行简单的求和(因为它在训练数据示例中看到了这种用法)。如果引入这种依赖项不值得,您可以切换到纯 Python 或您想要使用的库。
If the code uses a library, ensure it’s one you want to use (and that it’s available). Sometimes it might use, say, numpy for a simple sum (because it saw that in examples in its training data). If dragging in that dependency isn’t worth it, you can switch to pure Python or the library you intended.
有时,AI 代码可能会出现一些小的不一致之处,例如函数文档字符串的描述与代码的实际执行情况不符(例如,如果修改了逻辑但没有修改注释)。请修复这些问题。
Occasionally, the AI code might have minor inconsistencies, like a function docstring saying one thing but the code doing another (if it revised the logic but not the comment, for instance). Fix those.
This is rare with well-tested models but not impossible in languages where it might confuse something.
例如,人工智能可能会使用已更改的库函数的旧版本。如果您看到不认识的函数调用,请快速查看库文档,以确保它与您使用的版本兼容。
The AI might use an old version of a library’s function that has changed, for instance. If you see a function call you don’t recognize, quickly check the library docs to ensure it’s correct for the version you use.
If the AI output uses placeholders like “Your code here” (rare, but it can happen in a generic template), fill those in.
简而言之,要把AI代码当作实习生写的,然后就下班了。你需要审核代码质量,并正确地将其集成到系统中。
In short, treat the AI code as if an intern wrote it and left for the day. You need to review it for quality and integrate it properly.
假设你运行代码(或者为其编写测试,我们稍后会介绍),但有些地方出了问题。调试 AI 生成的代码与调试自己或他人的代码并无不同——只是代码不是你写的,所以你可能不太熟悉。但由于你已经仔细阅读过代码,所以你的情况应该不错(参见图 5-1)。
Let’s say you run the code (or write tests for it, which we’ll cover soon) and something’s not working. Debugging AI-generated code is no different than debugging your own or someone else’s code—except you didn’t write it, so you might be less familiar. But because you’ve carefully read it already, you’re in good shape (see Figure 5-1).
以下是六个步骤的调试方法:
Here’s a six-step approach to debugging:
重现该问题。
使用会失败的输入运行函数或代码。观察输出或错误信息。
Reproduce the issue.
Run the function or code with inputs that fail. Observe the output or error.
找出问题的根源。
使用常见的调试技巧,例如打印语句,或者使用调试器单步执行。如果是逻辑错误(输出错误),请手动或通过打印语句跟踪逻辑,找出与预期不符的地方。
Locate the source of the issue.
Use typical debugging techniques like print statements, or use a debugger to step through. If it’s a logical error (wrong output), trace the logic manually or with prints to see where it diverges from your expectations.
请将提示信息与代码进行比对。
有时,错误仅仅是因为代码没有完全实现需求,例如,你要求对某些内容进行排序,但它并没有正确排序。这可能意味着人工智能的逻辑存在缺陷,或者某些特殊情况(例如空列表)没有得到处理。
Check the prompt against the code.
Sometimes the bug is simply that the code didn’t fully implement the requirement, like if you asked for something to be sorted but it isn’t sorting properly. That might mean the AI’s logic is flawed or that an edge case (like an empty list) isn’t handled.
利用人工智能进行调试!
实际上,你可以把有问题的代码反馈给人工智能,然后说:“这段代码对 X 给出了错误的结果。你能帮忙找出错误吗?” 通常情况下,它会分析代码(就像代码审查一样),并指出问题所在。例如,它可能发现循环应该跳转到 `x`,len(arr)但却跳转到了 ` len(arr)-1y`。它或许能更快地发现这个问题。(但也要注意不要完全信任它——但这就像请同事帮忙调试一样。)
Leverage the AI to debug!
You can actually feed the problematic code back into the AI and say, “This code is giving the wrong result for X. Can you help find the bug?” Often, it will analyze it (like a code review) and point out issues. For example, maybe it sees that a loop should go to len(arr) but goes to len(arr)-1. It might catch that quicker. (Be mindful to not fully trust it either—but it’s like asking a colleague to help debug.)
修复代码。
现在你有两个选择:手动修复或提示 AI 生成修正版本。如果修正显而易见,直接修改即可。如果并非如此,你可以尝试类似这样的语句:“上述函数在输入 X 时出错(预期值为 Y,实际值为 Z)。请修正它。” AI 可能会据此调整代码。
Fix the code.
Now you have a choice: fix it manually or prompt the AI for a corrected version. If the fix is obvious, just do it. If it’s not, you can try something like “The above function fails on input X (expected Y, got Z). Please correct it.” The AI might then adjust the code accordingly.
再测试一次。
确保问题已解决,且未引入新的问题。
Test again.
Ensure the bug is resolved and that no new issues have been introduced.
我建议采用测试驱动调试法。如果可能,为关键函数编写一些测试(本章后面的测试部分会详细介绍)。任何失败的测试都会直接显示问题所在。除了最简单的函数之外,这种方法比手动检查要快得多。
I recommend using test-driven debugging. If possible, write a few tests for critical functions (more on that in the testing section later in this chapter). Any failing tests will directly show what’s wrong. This can be faster than manual checking, for anything but the simplest functions.
最后,调试时一定要问为什么,而不仅仅是问是什么。试着理解人工智能犯错的原因。提示信息是否不够清晰?这可以帮助你改进下次的提示方式,或者是否需要每次都仔细检查人工智能输出的这部分内容。例如,如果你发现人工智能经常无法处理空输入(除非明确告知),那么你就需要在提示信息中明确说明这一点,并定期检查。
Finally, when debugging, be sure you ask why, not just what. Try to understand why the AI made the mistake. Was the prompt unclear on that point? This can inform how you prompt next time or whether you need to always double-check that aspect in AI outputs. For example, if you notice the AI often doesn’t handle empty inputs unless told, you’ll start always specifying that in prompts and reviewing for it.
一旦代码功能正确,请考虑对其进行重构,使其符合项目标准,并使其在将来更容易使用。人工智能的任务是快速生成代码;你的任务是润色代码。
Once the code is functionally correct, consider refactoring it to align with your project’s standards and to make it easier to work with in the future. The AI’s job was to get you code quickly; your job is to polish it.
以下是另一个六步流程,这次是用于重构的:
Here is another six-step process, this time for refactoring:
使用代码格式化工具或代码检查工具检查代码。修复诸如“变量名应为小写”或“行过长”之类的警告。这样就能立即让代码看起来与代码库的其他部分保持一致。许多人工智能工具在代码风格方面做得不错,但可能仍需要进行一些细微的调整。
Run the code through your formatter or linter. Fix any warnings like “Variable name should be lowercase” or “Line too long.” This instantly makes the code look like the rest of your codebase. Many AI tools do a decent job at style, but slight adjustments might be needed.
改进命名和结构。
如果AI 为类中的函数命名_helper1,_helper2而你更喜欢有意义的名称,那就重命名它们。如果它创建了一堆只使用一次的小函数,除非它们能提高代码清晰度,否则可以考虑将它们内联。
Improve naming and structure.
If the AI named functions _helper1 and _helper2 in a class, and you prefer meaningful names, rename them. If it created a bunch of small functions that are only used once, maybe inline them, unless they add clarity.
去除所有不必要的部件。
例如,人工智能可能在输出中包含了你并未要求的程序块或测试代码。如果你不需要这些代码,请将其删除。反之,它可能将所有内容都写在一个函数中,但你希望将其拆分成更小的部分以提高清晰度;如果是这样,请立即进行拆分。
Remove any unnecessary parts.
For example, perhaps the AI included a main block or test code in the output that you didn’t ask for. If you don’t need that, remove it. Conversely, maybe it wrote everything in one function but you want to split it into smaller pieces for clarity; if so, do that split now.
添加文档。
如果这段代码打算作为库或模块的一部分供他人使用,请在适当的地方添加文档字符串或注释。人工智能可能已经添加了一些注释,但请确保其符合您的标准。例如,您的项目可能要求使用特定的文档字符串格式,并对参数和返回值进行文档化。
Add documentation.
If this code is intended to be part of a library or a module that others will use, add docstrings or comments where appropriate. The AI might have commented some, but ensure it meets your standards. For example, maybe your project requires a certain docstring format with parameters and returns documented.
如有需要,可进行优化。
现在代码可以运行了,它的效率足够高吗? 如果这段代码可能会在紧密循环或处理大数据时被调用,请检查其复杂度。人工智能可能没有使用最优解(再次强调,“多数派解决方案”可能只是一个简单的循环,而非更优化的方法)。如果性能是您关注的问题,请重构为更优的算法。您可以再次让人工智能参与进来:
通过使用集合而不是列表进行查找来优化此代码,使其运行速度更快。
但是,作为开发人员,你通常知道自己想要什么样的模式,所以你可能会直接实施这种改变。
Optimize if needed.
Now that the code works, is it efficient enough? If this code might be called in a tight loop or on large data, check its complexity. The AI might not have used the most optimal approach (again, the “majority solution” might be a simple loop, not a more optimized approach). If performance is a concern, refactor to a better algorithm. You can again involve the AI:
Optimize this code to run faster by using a set instead of a list for lookups.
But you, as a developer, often know what pattern you want, so you might just implement that change.
必要时可简化。
有时人工智能代码会过于冗长。例如,它可能使用带有返回值的 if-else 语句,而实际上只需一个带有条件的 return 语句就足够了。虽然显式编写代码并非一定不好,但为了提高可读性而不失清晰度,您可能需要将其简化为更少的行数。
Simplify if needed.
Sometimes AI code can be overly verbose. For instance, it might use an if-else with returns where a single return with a condition would suffice. While explicit code is not necessarily bad, you might want to simplify it to fewer lines to improve readability without losing clarity.
重构的目标是,如果其他开发者日后查看这段代码,不应该一眼看出“这是AI写的”,而应该看起来就像是优秀的代码。这通常意味着要进行一些细微的人为润色,使代码更加简洁清晰。
The goal of refactoring is that if another developer pulls up this code later, it shouldn’t be obvious that “an AI wrote this.” It should just look like good code. That often means giving it the small human touches that make code clean.
重构时,你需要验证是否破坏了任何东西。所以接下来我们来谈谈测试。
When you refactor, you need to verify you didn’t break anything. So let’s segue into testing.
测试总是很重要的,但对于人工智能生成的代码来说尤其重要,原因有二。 首先,由于这不是你从零开始编写的,你需要确保它在任何情况下都能正常运行。其次,如果你之后需要对 AI 进行修改或集成更多 AI 代码,测试可以帮助你确保任何新的修改都不会破坏现有功能。让我们快速了解一下不同类型的测试:
Testing is always important, but it’s especially important for AI-generated code for two reasons. First, since you didn’t write it from scratch, you want assurance that it will work in all cases. Second, if you prompt the AI for changes later or integrate more AI code, tests help you ensure that any new changes don’t break the existing functionality. Let’s look quickly at different kinds of tests:
为从 AI 获取的每个函数或模块编写测试,尤其要涵盖边界情况。以我们的例子为例,你可以用质数、非质数、1(边界情况)、0 或负数(可能用来定义预期行为)、大质数等等进行测试。如果代码通过了所有这些测试,那么它很可能是正确的。
Write tests for each function or module you got from the AI, particularly covering edge cases. For our prime example, you might test with a prime number, a nonprime, 1 (an edge case), 0 or negative (maybe defining the expected behavior), a large prime, and so on. If the code passes all those tests, it’s likely correct.
你甚至可以让人工智能生成这些测试:
You can even ask the AI to generate these tests:
为上述函数编写 PyTest 单元测试,覆盖各种边界情况。
Write PyTest unit tests for the above function, covering edge cases.
它通常能很好地完成任务。不过,最好还是仔细检查一下,确保它们有效且涵盖了你认为必要的内容。
It often does a decent job. Still, review them to ensure they’re valid and cover what you think is necessary.
如果人工智能代码如果某个函数与其他代码库部分交互(例如,使用数据库的函数),请编写一个测试来在上下文中调用它。它是否真的将应该存储的数据存储到数据库中?如果它产生了被其他函数使用的输出,请将它们链接起来进行测试。
If the AI code interacts with other parts of the codebase, like a function that uses a database, write a test that calls it in context. Does it actually store to the database what it should? If it produces output consumed by another function, chain them in a test.
如果这段代码是部分对于更大型的工作流程,请从头到尾运行一个场景。例如,如果 AI 代码是 Web 路由的一部分,请在测试环境中向该路由发送测试请求,并检查格式、错误处理以及其他所有方面是否正常。
If this code is part of a larger workflow, run a scenario from start to finish. For example, if the AI code was part of a web route, do a test request to that route in a test environment and see if the format, error handling, and everything else holds up.
你需要进行的测试级别取决于代码的关键性和复杂程度。但即使是快速的手动测试运行或在脚本中添加简单的断言语句,也比什么都不做要好得多。记住,测试不仅仅是为了发现错误;它还能锁定行为。如果你之后更改了某些内容(或者人工智能进行了更改),测试可以帮助你确保代码的功能不会退化。
The level of testing you need to do depends on how critical and complex the code is. But even a quick manual test run or simple assert statements in a script are better than nothing for verification. Remember, testing doesn’t just find bugs; it locks down behavior. If you change something later (or an AI does), testing helps you ensure the code’s functionality doesn’t regress.
测试也是确立所有权的好方法。一旦你测试并修复了所有问题,你就可以对代码充满信心。此时,你可以说这段代码“属于你”,就像代码库中的任何其他代码一样。你理解它,你信任它,并且你编写了测试来保护它。
Testing is also a good way to assert ownership. Once you’ve tested for and fixed any issues, you can be confident in the code. At this point, it’s fair to say the code is “yours,” just like any other code in the codebase. You understand it, you trust it, and you have tests to guard it.
一些人工智能编码工具开始整合测试建议。例如,CodeWhisperer 有时会在一段代码后建议添加断言。你可以将这些建议作为起点,但不要认为它们涵盖了所有情况。要考虑一些有创意的极端情况——在这方面,人类的直觉仍然非常宝贵。
Some AI coding tools are starting to integrate testing suggestions. For example, CodeWhisperer will sometimes suggest an assert after a piece of code. Use those suggestions as a starting point, but don’t assume they’re 100% comprehensive. Think of creative edge cases—that’s one place where human intuition is still very valuable.
我们已经完成了代码的生成、理解、调试和重构。这个循环可能在很短的时间内完成(对于小型函数,可能只需几分钟),也可能需要更长时间(对于复杂的模块,可能需要数小时或数天,并间歇性地借助人工智能辅助)。
We’ve gone through generating, understanding, debugging, and refactoring the code. This loop might happen in a short span (within minutes, for a small function) or take longer (for a complex module, over hours or days, with intermittent AI assistance).
这很重要开发者需要对最终代码负责。人工智能是加速创作的工具,但如果出现问题,它不会承担责任。此外,还存在许可或版权风险:一些人工智能提供商表示,超过一定长度的输出结果在统计学上可能包含抄袭内容。这种情况虽然罕见,而且提供商也已尽力缓解,但就像你在 Stack Overflow 的回答中会检查是否存在明显的许可文本或署名一样,最好还是快速检查一下——尤其是在输出结果很大或过于简洁的情况下。例如,如果你要求“实现快速排序”,而人工智能给出了 20 行干净的代码,这可能没什么问题,而且是常识。但如果你要求的是一些比较冷门的内容,而得到的却是一大段代码,那么可以尝试在网上搜索其中的一个特定字符串,看看它是否是从其他地方逐字复制的。最近,这个问题变得越来越明显,一些人工智能系统复制期刊文章和其他受版权保护的来源的文本的案例已被记录在案。作为负责任的代码所有权的一部分,开发人员应该验证任何超出通用模式或似乎异常地针对特定来源的 AI 生成内容的来源。
It’s important to acknowledge that you, the developer, are responsible for the final code. AI is a tool to accelerate creation, but it won’t take the blame if something fails. There’s also a licensing or copyright risk: some AI providers say that outputs over a certain length might be statistically likely to contain copied material. It’s rare, and the providers mitigated the problem a lot, but just as you scan Stack Overflow answers for any obviously licensed text or attributions, do a quick check—especially if the output is big or too clean. For instance, if you prompt “implement quicksort” and the AI gives you 20 lines of pristine code, that’s probably fine and common knowledge. But if you ask for something obscure and get a large chunk of code, try searching a unique string from it online to see if it was pulled verbatim from somewhere. This issue has become more apparent recently, with documented cases of AI systems reproducing text from journal articles and other copyrighted sources. As part of responsible code ownership, developers should verify the provenance of any AI-generated content that appears to go beyond generic patterns or seems unusually specific to particular sources.
最后,将代码集成到你的项目中:将其添加到版本控制系统中,并在提交信息中注明人工智能为此做出了贡献。虽然这不是强制性的,但有些团队喜欢跟踪代码的贡献。
Finally, integrate the code into your project: add it to your version control system, perhaps mentioning in your commit message that AI helped. There’s no requirement to do this, but some teams like to track it.
随着时间的推移,需求的变化可能会导致您需要修改这段由人工智能生成的代码。请像对待其他代码一样对待它:不要想着“哦,这是人工智能生成的代码,我可以让它修改”。当然,如果您愿意,可以修改它,但您也可以自由地手动修改。选择最高效、最易于维护的方式即可。
Over time, you’ll likely modify this AI-generated code as requirements change. Treat it like any other code: don’t think, “Oh, that’s the AI’s code; I’ll ask the AI to change it.” You can, if you want, but you can also freely modify it by hand. Do whatever is most efficient and maintainable.
经过仔细审查和测试,AI生成的代码最终会成为项目中的又一段代码。此时,第10行代码是AI写的还是你写的已经无关紧要——重要的是它满足项目的需求和标准。
Through careful review and testing, AI-generated code becomes just more code in your project. At that point, whether an AI wrote line 10 or you did is irrelevant—what matters is that it meets the project’s needs and standards.
遵循这些实践,您既能利用人工智能编码的速度优势,又能确保质量。您可以避免盲目信任人工智能输出的弊端,并将其融入到专业的开发工作流程中。
By following these practices, you harness the speed of AI coding while ensuring quality. You avoid the pitfalls of unquestioningly trusting AI output and instead integrate it into a professional development workflow.
接下来,第六章将探讨人工智能工具如何从根本上改变软件开发的原型设计阶段。我将探索利用人工智能助手加速从初始概念到可运行原型转变的实用技巧,通常可以将开发时间从几天缩短到几小时。讨论内容涵盖具体的人工智能原型设计工具,包括 Vercel v0 和屏幕截图转代码工具,以及在人工智能指导下进行迭代改进的策略。
Next, Chapter 6 examines how AI tools can fundamentally transform the prototyping phase of software development. I will explore practical techniques for leveraging AI assistants to accelerate the journey from initial concept to working prototype, often reducing development time from days to hours. The discussion covers specific AI-powered prototyping tools, including Vercel v0 and screenshot-to-code utilities, along with strategies for iterative refinement under AI guidance.
我还会探讨从人工智能生成的原型到可用于生产环境的代码这一关键过渡过程,分析当人工智能成为开发工作流程的核心部分时所带来的机遇和潜在挑战。通过真实案例研究,我将展示开发人员如何成功地利用人工智能快速测试想法,同时保持代码质量,并避免从概念到实现过快过程中可能出现的常见陷阱。
I will also address the critical transition process from AI-generated prototypes to production-ready code, examining both the opportunities and potential challenges that arise when AI becomes a central part of the development workflow. Through real-world case studies, I will demonstrate how developers are successfully using AI to test ideas rapidly while maintaining code quality—and avoiding common pitfalls that can emerge when moving too quickly from concept to implementation.
本章探讨了人工智能驱动的氛围编码如何加速软件开发的原型设计阶段。原型设计的核心在于快速将想法转化为可运行的模型。借助人工智能助手,开发者可以在数小时内完成通常需要数天才能完成的工作,从而快速迭代概念。我将探讨如何利用人工智能将概念转化为原型,比较常用的人工智能原型设计工具(包括 Vercel v0 和截图转代码工具),并研究如何在人工智能的指导下迭代改进原型。此外,我还会重点介绍将人工智能生成的粗略原型转化为生产级代码的关键步骤。在本章中,我还会分析一些人工智能驱动原型设计取得成功的案例,并展示这种方法的潜力和不足之处。
This chapter explores how AI-driven vibe coding accelerates the prototyping phase of software development. Prototyping is all about rapidly turning an idea into a working model. With AI assistants, developers can achieve in hours what might normally take days, quickly iterating on concepts. I’ll discuss techniques for going from concept to prototype with AI, compare popular AI prototyping tools (including Vercel v0 and screenshot-to-code utilities), and examine how to refine prototypes iteratively under AI guidance. I also address the crucial step of transitioning a rough AI-generated prototype into production-quality code. Throughout the chapter, I’ll also look at case studies where AI-driven prototyping led to successful outcomes and demonstrate both the potential and the pitfalls of this approach.
人工智能生成的代码速度快,这对原型设计大有裨益。原型设计的目标不是编写精良的、可用于生产的代码,而是验证概念,以便进行评估和改进。AI 编码助手在这里大放异彩,只需极少的输入就能快速生成可运行的代码。例如,开发者无需手动编写 UI 模型,只需用自然语言描述所需的界面,即可让 AI 生成 HTML/CSS 或 React 组件。这大大缩短了从构思到实现的周期。
Prototyping benefits greatly from the speed of AI-generated code. The goal in prototyping is not polished, production-ready code but a proof of concept that you can evaluate and refine. AI coding assistants shine here by producing functioning code quickly from minimal input. For example, instead of manually coding a UI mockup, a developer can describe the desired interface in natural language and let the AI generate the HTML/CSS or React components. This allows for a very fast idea-to-implementation cycle.
一位用户体验工程师描述了使用生成式人工智能工具如何彻底改变了他的工作流程:“生成式人工智能生成功能原型的速度令人惊叹。我几个小时就能完成通常需要几天才能完成的原型。”人工智能可以自动处理常规的样板代码和重复模式,让他能够专注于更高层次的设计决策。在原型制作中,这意味着你可以在相同的时间内尝试更多的想法。另一个好处是,人工智能几乎可以瞬间填充原型中繁琐的部分(基本用户界面组件、表单处理、示例数据),使开发人员能够专注于正在测试的核心概念或独特功能。
One UX engineer describes how using a generative AI tool has completely transformed his workflow: “The speed at which I could generate functional prototypes with Generative AI was amazing. I built prototypes in a few hours [that] would normally take days.” The AI handles routine boilerplate and repetitive patterns automatically, freeing him to focus on higher-level design decisions. In prototyping, this means you can try out more ideas in the same amount of time. Another benefit is that AI can fill in the tedious parts of a prototype (basic UI components, form handling, sample data) almost instantly, allowing the human developer to concentrate on the core concept or unique feature being tested.
然而,需要记住的是,原型代码通常是一次性代码。人工智能可以快速生成一个可行的解决方案,但这些代码的结构可能不利于维护或扩展。这在原型阶段是可以接受的,因为速度和实验比优雅性更重要——只要你计划在生产环境中重构或重写关键部分(我将在本章后面讨论这个过程)。正如第3章和第4章所探讨的,人工智能可以自信地处理原型中大约70%的编码工作,而你可以指导整体架构并纠正任何关键缺陷。
However, it’s important to remember that a prototype’s code is often throwaway code. An AI may generate a working solution quickly, but that code might not be structured for maintainability or scale. This is acceptable in prototypes, where speed and experimentation matter more than elegance—as long as you plan to refactor or rewrite critical parts for production (I’ll discuss this process later in the chapter). As Chapters 3 and 4 explored, the AI can confidently handle about 70% of the coding for a prototype, while you guide the overall architecture and correct any critical flaws.
第一章介绍的“意图编程”概念在这里至关重要。你只需提供高层次的指令(即你希望原型实现的功能或外观),然后让人工智能来完成具体的实现。为了说明这一点,让我们通过一个使用人工智能助手的非常简单的原型设计示例来了解一下。假设您有一个关于新服务注册页面的想法。你想快速搭建前端原型,所以你从以下开发者提示开始:
Programming with intent, a concept introduced in Chapter 1, is essential here. You provide high-level instructions (the intent of what you want the prototype to do or look like) and let the AI fill in the implementation. To illustrate, let’s walk through a very simple prototyping example using an AI assistant. Suppose you have an idea for a sign-up page for a new service. You want to prototype the frontend quickly, so you start with the following developer prompt:
创建一个简单的HTML页面,用于制作注册表单,包含姓名、邮箱和密码三个字段,以及一个提交按钮。使用基本的样式使其外观美观。
Create a simple HTML page for a sign-up form with fields for Name, Email, and Password, and a Submit button. Make it look presentable with basic styling.
现代代码助手就像克莱恩可能那样请提供完整的HTML/CSS示例:
A modern code assistant like Cline might provide a complete HTML/CSS example:
<!DOCTYPE html><htmllang="en"><head><metacharset="UTF-8"/><metaname="viewport"content="width=device-width, initial-scale=1.0"/><title>注册</title><style>body{font-family:Arial,sans-serif;max-width:400px;margin:2emauto;}form{display:flex;flex-direction:column;}label{margin-top:1em;}input,button{padding:0.5em;font-size:1em;}button{margin-top:1em;background:#4CAF50;color:#fff;border:none;}</style></head><body><h2>注册</h2><form><label>姓名:<inputtype="text"name="name"required></label><label>邮箱:<inputtype="email"name="email"required></label><label>密码:<inputtype="password"name="password"required></label><buttontype="submit">创建账户</button></form></body></html>
<!DOCTYPE html><htmllang="en"><head><metacharset="UTF-8"/><metaname="viewport"content="width=device-width, initial-scale=1.0"/><title>Sign Up</title><style>body{font-family:Arial,sans-serif;max-width:400px;margin:2emauto;}form{display:flex;flex-direction:column;}label{margin-top:1em;}input,button{padding:0.5em;font-size:1em;}button{margin-top:1em;background:#4CAF50;color:#fff;border:none;}</style></head><body><h2>Sign Up</h2><form><label>Name:<inputtype="text"name="name"required></label><label>Email:<inputtype="email"name="email"required></label><label>Password:<inputtype="password"name="password"required></label><buttontype="submit">Create Account</button></form></body></html>
这段由人工智能生成的代码为注册表单原型提供了一个不错的起点。它包含一个基本布局和一些用于样式设置的内联 CSS。作为开发者,您无需手动编写任何 HTML/CSS 代码——您只需描述最终效果,人工智能就会提供相应的实现。这体现了“意图驱动型编程”的理念:您专注于用户界面应该实现的功能,而人工智能则负责找到实现方法。
This AI-generated code is a decent starting point for a prototype of the sign-up form. It includes a basic layout and some inline CSS for styling. As a developer, you didn’t have to write any HTML/CSS by hand—you simply described the outcome, and the AI provided an implementation. This demonstrates programming by intent: you focus on what the UI should do, and the AI figures out how to do it.
当然,这只是一个简单的例子。在实践中,原型可能更复杂,涉及多个文件、框架或数据。但原理是一样的:使用人工智能快速创建初稿。然后,您可以在浏览器中打开此原型,查看其效果,并进一步完善。这就引出了下一个话题:使用功能更强大的专用人工智能原型工具。简明易懂的提示语。
Of course, this is a trivial example. In practice, prototypes can be more complex and involve multiple files, frameworks, or data. But the principle is the same: You use the AI to create a first draft swiftly. You might then open this prototype in a browser, see how it looks, and refine it further. That leads me to the next topic: using specialized AI prototyping tools that go beyond plain-language prompts.
通用助理喜欢Gemini、ChatGPT 和 Claude 等工具能够根据提示生成原型代码,而专门的 AI 辅助原型工具领域仍在快速发展。在我撰写本文时,现有工具针对 AI 生成原型中保真度和控制性之间的根本权衡问题,提供了不同的解决方案。
While general-purpose assistants like Gemini, ChatGPT, and Claude can generate prototype code from prompts, the landscape of specialized AI-assisted prototyping tools continues to evolve rapidly. As I write this, the available tools offer different approaches to the fundamental trade-off between fidelity and control in AI-generated prototypes.
该生态系统已经成熟,能够满足不同的原型设计需求。有些工具擅长将视觉设计转换为代码,设计师只需上传屏幕截图或草图,即可在几秒钟内获得可用的 HTML、CSS 或 React 组件。这种“屏幕截图转代码”功能极大地加快了开发速度。设计到代码的转换过程,在需要快速实现手绘草图或 Figma 设计稿时尤为重要。Vercel v0 等工具正是这种方法的典范,它能在保证高度还原原始设计的同时,牺牲对代码结构的某些控制权。
The ecosystem has matured to serve distinct prototyping needs. Some tools excel at transforming visual designs into code, allowing designers to upload screenshots or sketches and receive working HTML, CSS, or React components within seconds. This “screenshot-to-code” capability dramatically accelerates the design-to-code process, particularly valuable when you have hand-drawn sketches or Figma designs that need rapid implementation. Tools like Vercel v0 exemplify this approach, offering high fidelity to the original design while trading off some control over code structure.
其他平台则专注于通过对话式界面生成完整的应用程序。这些工具允许用户用自然语言描述功能,并获得完整的实现方案。例如,想要快速搭建应用程序而无需编写代码的设计师可以使用 Lovable 或 Bolt.new 等工具,它们提供高级提示界面,可以快速构建完整的应用程序。一些设计师表示,人工智能可以在几个小时内构建出原本需要几天才能完成的功能原型,它会自动处理繁琐的组件和模式。
Other platforms focus on generating complete applications through conversational interfaces. These allow users to describe functionality in natural language and receive full stack implementations. For instance, a designer wanting a quick app without coding might use tools like Lovable or Bolt.new, which offer high-level prompt interfaces that can scaffold entire applications. Some designers report building functional prototypes in hours that would traditionally take days, with the AI automatically handling tedious components and patterns.
第三类是将人工智能直接集成到开发环境中,在原型设计阶段充当智能结对程序员。这些人工智能增强型 IDE,如 Cursor、Windsurf 和 Cline,使开发人员能够在享受人工智能加速的同时,更好地控制代码生成过程。区别往往在于工作流程理念:有些工作流程优先考虑自动应用更改以进行快速实验,而另一些工作流程则要求明确接受修改以进行更仔细的迭代。
A third category integrates AI directly into development environments, functioning as intelligent pair programmers during the prototyping phase. These AI-augmented IDEs like Cursor, Windsurf, and Cline allow developers to maintain more control over the code generation process while still benefiting from AI acceleration. The distinction often lies in workflow philosophy: some prioritize automated application of changes for rapid experimentation, while others require explicit acceptance of modifications for more careful iteration.
所有这些方法的共同之处在于它们都能缩短从概念到可运行原型的开发周期。然而,它们在两个关键维度上存在显著差异,这两个维度决定了它们对不同用户和使用场景的适用性。
The common thread across all these approaches is their ability to compress the journey from concept to working prototype. However, they differ significantly in two key dimensions that shape their utility for different users and use cases.
富达指的是生成的输出与您的输入或意图的匹配程度如何?截图转代码工具通常能高度还原视觉设计,但生成的代码可能与您的架构偏好不符。对话式工具可能对您的需求理解得更宽泛,生成功能齐全但通用的实现,需要进一步完善。
Fidelity refers to how closely the generated output matches your input or intention. Screenshot-to-code tools typically offer high fidelity to visual designs but may produce code that doesn’t align with your architectural preferences. Conversational tools might interpret your requirements more loosely, generating functional but generic implementations that require refinement.
控制权包括你指导和修改生成过程的能力。有些工具像黑盒一样运行,直接输出完整的结果;而另一些工具则允许通过持续的交互或直接编辑代码进行迭代改进。当需要特定的架构模式、性能优化或与现有代码库集成时,这种特性就显得至关重要。
Control encompasses your ability to guide and modify the generation process. Some tools operate as black boxes that produce complete outputs, while others allow iterative refinement through continued dialogue or direct code editing. This dimension becomes crucial when you need specific architectural patterns, performance optimizations, or integration with existing codebases.
了解这些权衡取舍有助于选择适合原型设计需求的工具。例如,设计师在验证新的交互模式时,可能会优先考虑保真度和速度,而对实现细节的控制权则可能较低。而开发人员在探索技术可行性时,则可能更看重控制权和透明度,即使这意味着在生成过程中需要更多的人工干预。
Understanding these trade-offs helps in selecting the right tool for your prototyping needs. A designer validating a new interaction pattern might prioritize fidelity and speed, accepting less control over implementation details. A developer exploring technical feasibility might value control and transparency, even if it means more manual intervention in the generation process.
如果没有人工监督,这些工具都无法生成生产级代码。他们通常交付的是我所谓的“80%原型”——功能足以测试概念并向利益相关者演示,但要部署到生产环境还需要额外工作。剩余的20%通常涉及安全加固、性能优化、错误处理和架构改进。
None of these tools produces production-quality code without human oversight. They typically deliver what I call the “80% prototype”—functional enough to test concepts and demonstrate to stakeholders but requiring additional work for production deployment. The remaining 20% often involves security hardening, performance optimization, error handling, and architectural refinement.
即使在快速原型开发阶段,快速代码审查仍然至关重要。虽然你可能无法完善原型中的每个细节,但扫描诸如暴露的 API 密钥或不安全的数据处理等显而易见的问题,可以防止问题蔓延到后续开发阶段。大多数现代工具都提供了生成代码的透明性,使你可以检查并了解正在创建的内容。
Even during rapid prototyping, a quick code review remains essential. While you might not polish every detail in a prototype, scanning for obvious issues like exposed API keys or insecure data handling prevents problems from propagating into later development stages. Most modern tools provide transparency into their generated code, allowing you to inspect and understand what’s being created.
随着人工智能原型设计领域的不断发展,具体工具无疑会随之改变,但保真度与控制力之间的权衡以及人工监督的必要性等基本考量将始终不变。关键在于理解原型设计的目标,并选择符合自身需求的方案,无论是快速可视化实现、功能演示还是技术探索。
As the AI prototyping landscape continues to evolve, the specific tools will undoubtedly change, but these fundamental considerations of fidelity versus control, and the need for human oversight, will remain constant. The key is understanding your prototyping goals and selecting approaches that align with your specific needs, whether that’s rapid visual implementation, functional demonstration, or technical exploration.
其中一项优势是AI驱动的原型设计是一个迭代循环:您可以生成初始版本,然后通过与AI交互来完善它。 无需手动编辑代码,只需告诉人工智能你想修改什么即可(见图6-1)。虽然我提倡比纯粹凭感觉编写代码更负责任的方法,但快速反馈循环在原型开发中绝对是值得借鉴的优势。
One of the strengths of AI-driven prototyping is the iterative loop: you can generate an initial version and then refine it by interacting with the AI. Instead of manually editing code, you just tell the AI what you want changed (see Figure 6-1). While I advocate a more responsible approach than pure “seat-of-the-pants” vibe coding, the fast feedback cycle is definitely something to embrace in prototypes.
大多数人工智能原型工具都会保留请求的历史记录或上下文,这非常有用。这意味着人工智能会记住你的应用用途和之前的指令,因此你无需每次都重新解释所有内容。这种上下文持久性是“氛围编码”环境的标志性特征:与人工智能的对话本身就成为了开发日志。
Most AI prototyping tools keep a history or context of your requests, which is extremely useful. It means the AI remembers the purpose of your app and previous instructions, so you don’t have to re-explain everything each time. This context persistence is a hallmark of vibe-coding environments: the conversation with the AI becomes the development log.
以下是一个典型的迭代改进过程:
Here’s how a typical iterative refinement might go:
您提供提示或输入以创建原型:
创建一个基本的费用跟踪应用程序,包含一个用于添加费用的表单和一个用于列出费用的表格。
You provide a prompt or input to create the prototype:
Generate a basic expense-tracker app with a form to add expenses and a table to list them.
你拿到生成的代码并运行它。也许它能运行,但你注意到一些可以改进的地方。例如,用户界面功能齐全但略显简陋,或者表格没有对费用进行排序。
You get the generated code and run it. Maybe it works, but you notice some things that could be improved. For example, the UI is functional but plain, or the table doesn’t sort the expenses.
You go back to the AI and provide additional instructions. For instance:
使费用清单可以按金额或日期排序。
Make the expense list sortable by amount or date.
人工智能可能会修改代码以包含排序逻辑,或者使用可排序表格库:
The AI might modify the code to include sorting logic or use a library for sortable tables:
添加一些颜色样式,或许可以使用现代的 CSS 框架。
Add some color styling, maybe use a modern CSS framework.
The AI could integrate a CSS library (like Tailwind or Bootstrap) or just add custom styles to make it look nicer:
验证表单,使其无法添加未填写名称和金额的费用。
Validate the form so you can’t add an expense without a name and amount.
人工智能可能会增加简单的前端验证功能。
The AI might add simple frontend validation.
这些提示都会对原型进行修改。由于人工智能能够理解上下文(诸如 Cursor 之类的工具和持续的聊天工具会保留代码状态),因此它通常能够将更改应用到正确的位置——例如,在表单中插入验证代码或重写表格渲染以包含可排序的列。
Each of these prompts modifies the prototype. Because the AI understands the context (tools like Cursor and ongoing chat tools will keep the code state), it can often apply changes in the right places—for example, inserting validation code in the form or rewriting the table rendering to include sortable columns.
每次改进后,你都要检查结果。如果人工智能引入了新问题或没有完全按照你的预期运行,你需要通过提示进行澄清或修复:
排序方式错误——请默认按升序排序。
新的配色方案不错,但应该把标题颜色改成深蓝色而不是黑色。
After each refinement, you check the result. If the AI introduced a new issue or didn’t do exactly what you intended, you clarify or fix it via prompts:
The sorting is backward—please sort ascending by default.
The new color scheme is good, but make the header dark blue instead of black.
每次迭代周期都非常快——通常只需几秒钟的处理时间——这意味着你可以在一小时内完成十几次迭代。与手动编写代码并检查所有更改相比,人工智能方法可以显著提高速度。对于像重新设计样式或添加新功能这样的大幅度更改,这一点尤其明显。
Each iteration cycle is quite fast—often taking just a few seconds of processing—which means you can go through a dozen iterations within an hour. Compared to manually coding and checking all those changes, the AI approach can be significantly faster. That’s especially true for broad changes, like restyling or adding a feature.
重要的是,与人工智能进行迭代需要清晰的沟通。这就需要你运用提示工程技巧了。你对想要做的改变描述得越明确清晰,人工智能就越有可能正确执行。例如,说“让它看起来更美观”就很模糊。更具体的提示能给助手一个明确的方向:
Importantly, iterating with AI requires clear communication. This is where your prompt engineering skills come into play. The more explicit and clear you are about the change you want, the more likely the AI will do it correctly. For example, saying “Make it look nicer” is vague. A more specific prompt gives the assistant a concrete direction:
应用浅色主题,蓝色标题,并增大字体以提高可读性。
Apply a light theme with a blue header and increase the font sizes for readability.
如果你使用的是 Vercel v0 或 Lovable 之类的工具,你甚至可以使用其界面指向 UI 的某个部分,然后说:“把它改成 X”。
If you’re using a tool like Vercel v0 or Lovable, you might even point to a part of the UI using its interface and say, “Change this to X.”
让我们来看一个开发者和人工智能编码助手之间简短的对话迭代过程:
Let’s look at a short conversational iteration process between a developer and an AI coding assistant:
创建一个 React 组件,用于显示待办事项列表。该组件应显示任务列表和一个用于添加新任务的文本输入框。
Generate a React component for a to-do list. It should display a list of tasks and a text input to add a new task.
AI 会生成一个带有任务状态的 React 组件,并渲染一个列表、一个输入框和一个用于添加任务的按钮:
The AI produces a React component with state for tasks and renders a list, an input, and a button to add tasks:
太好了。现在把每个任务都设为可编辑状态,并添加一个复选框来标记任务完成。
Great. Now make each task editable and add a checkbox to mark it complete.
AI 更新代码,为每个任务添加复选框和编辑功能,并相应地修改任务状态。开发者运行应用后发现编辑功能正常,但没有删除按钮:
The AI updates the code, rendering each task with a checkbox and an edit function and modifying state accordingly. The developer runs the app and finds that editing works, but there’s no delete button:
为每个任务添加删除按钮。
Add a delete button for each task.
人工智能在代码中添加了删除功能:
The AI adds a delete feature in the code:
布局有点拥挤。添加一些基本的CSS代码来拉开列表项之间的间距,并将字体稍微放大一些。
The layout is a bit cramped. Add some basic CSS to space out the list items and make the font a bit larger.
人工智能输出CSS样式,可以放在<style>组件中,也可以放在单独的CSS代码片段中:
The AI outputs CSS styling, possibly as a <style> in the component or a separate CSS snippet:
看起来好多了!
Looks better!
这种反复修改可能会持续到原型符合预期为止。最终,开发者会得到一个待办事项应用的可用原型,具备创建、编辑、完成和删除功能——所有这些功能都是通过自然语言请求和快速生成的AI代码实现的。
This kind of back-and-forth could continue until the prototype meets the vision. In the end, the developer gets a working prototype for a to-do list app, with create, edit, complete, and delete functionalities—all built via natural-language requests and quick AI code outputs.
在整个过程中,请记住开发者始终掌控着一切。人工智能可能会提出实现某个功能的方法,但最终由您来决定它是否符合您的需求。有时,人工智能的实现方式虽然正确,但可能并非您所期望的(例如,它可能采用了与您设想不同的用户界面设计)。您可以接受它(前提是它不会影响原型目标),或者指示人工智能更改为您偏好的方法。
Throughout this process, remember that the developer remains the director of what happens. The AI might propose a way to implement a feature, but you decide if that fits your needs. Sometimes the AI’s implementation is correct but not what you expected (maybe it uses a different UI approach than what you had in mind). You can either accept it (if it doesn’t harm the prototype goals) or instruct the AI to change to your preferred approach.
原型旨在证明……它既是一个概念,也是一个学习哪些方法有效的工具。一旦它达到了预期目的——例如,你已经用用户验证了设计,或者证明了某个功能的可行性——下一步通常是将其转化为生产应用程序。这一过渡阶段至关重要。人工智能固然可以提供帮助,但开发人员仍需打磨原型中的粗糙之处。本节将探讨从原型过渡到生产代码时需要考虑的一些关键因素。
A prototype is meant to be a proof of concept and a tool for learning what works. Once it has served that purpose—say, you’ve validated the design with users or proven that a certain feature is feasible—the next step is often to turn it into a production application. This transition is a critical juncture. AI can still help, but human developers must sand down the rough edges of the prototype. This section looks at some key considerations when moving from prototype to production code.
首先,仔细检查架构和代码结构。原型底层可能比较混乱。也许所有代码都放在一个文件中,或者为了追求速度而忽略了一些最佳实践。现在是时候引入合理的结构了。例如,如果原型是一个单页脚本,可以将其拆分成多个模块;对于 Web 用户界面,可以引入合适的组件结构;对于后端,可以建立正式的模型-视图-控制器 (MVC) 架构模式。
First, review the architecture and code structure carefully. Prototypes can be messy under the hood. Perhaps all your code ended up in one file or you bypassed certain best practices for speed. Now is the time to introduce a proper structure. For example, if the prototype was a single-page script, you might separate it into multiple modules; for a web UI, you might introduce a proper component structure; for a backend, you might set up a formal model–view–controller (MVC) architectural pattern.
虽然原型的大部分代码是由人工智能编写的,但作为开发者,您最了解架构目标。您甚至可以创建一个新项目,并将原型作为参考或脚手架,或许会重用原型中的一些代码,但通常会将其视为一次性代码。其他人可能会逐步重构原型代码库,使其更符合需求,而人工智能则会提出重构建议或生成测试,以确保在清理过程中不会出现任何问题。
While AI wrote much of the prototype, you, as the developer, understand the architecture goals best. You might even start a fresh project and use the prototype as a reference or as scaffolding, perhaps reusing some of the prototype code but generally treating it as throwaway code. Others might incrementally refactor the prototype codebase into shape, with AI suggesting refactorings or generating tests to ensure nothing breaks during cleanup.
接下来,添加错误处理和边界情况处理。原型代码通常只关注正常情况,但如果 API 调用失败怎么办?如果输入为空怎么办?系统地检查每个功能,并考虑潜在的故障模式。
Next, add error handling and edge cases. Prototype code often focuses on the sunny-day scenario, but what if the API call fails? What if the input is empty? Go through each feature systematically and consider potential failure modes.
人工智能可以帮助你集思广益,找出各种极端情况,例如给出如下提示:
AI can help you brainstorm edge cases, given a prompt like this:
该功能可能出现哪些错误情况?如何处理这些错误?
What are potential error cases for this feature and how to handle them?
助手可能会列出一些场景(例如网络错误、输入错误、并发问题),您可以针对这些场景实现相应的处理(或者让 AI 协助实现)。确保代码的健壮性是使其达到生产就绪状态的关键步骤。
The assistant will likely list some scenarios (network errors, bad input, concurrency issues) for which you can implement handling (or ask AI to help implement it). Ensuring your code’s robustness is part of making it production-ready.
你的原型代码可能没有经过优化,所以要检查是否存在效率低下或可能存在安全隐患的部分。例如,原型中的人工智能可能使用了简单的算法,这种算法在小型测试数据集上表现良好,但在处理真实数据时速度会很慢。找出这些问题所在并进行优化。(我将在第 8 章介绍常见的人工智能生成代码缺陷。)
Your prototype code probably isn’t optimized, so check for any parts that are inefficient or could pose security issues. For instance, maybe the AI in the prototype used a naive algorithm that works on small test datasets but would be slow with real data. Identify such spots and optimize them. (I’ll cover common AI-generated code flaws in Chapter 8.)
一种策略是对原型进行性能测试或使用性能分析器来发现瓶颈,然后让AI帮助优化该功能。务必审查身份验证和数据处理等安全功能——AI原型使用未正确参数化的SQL查询(存在SQL注入攻击风险)或包含敏感信息的情况并不少见。这些问题必须得到解决。2021年的一项研究发现,约40%的AI生成代码存在潜在漏洞。因此,生产化过程中保持警惕至关重要。手动对代码运行静态分析和/或安全测试,或者提示 AI “扫描此代码是否存在安全问题”。
One strategy is to run performance tests or use profilers on the prototype to see bottlenecks, then ask AI to help optimize that function. Definitely review security features like authentication and data handling too—it’s not uncommon for AI prototypes to use SQL queries without proper parameterization (risking SQL injection attacks) or to include sensitive information. These problems must be fixed. A 2021 study found that about 40% of AI-generated code had potential vulnerabilities. So part of productionizing is staying vigilant. Run static analysis and/or security tests on the code manually, or prompt the AI to “scan this code for security issues.”
原型通常缺乏在规范代码的过程中,您需要添加文档:每个模块清晰且经过人工审核的解释,不仅对未来的团队成员有帮助,也能在几个月后您重新查看代码时有所帮助。代码清理完毕后,您可以借助 AI 工具,根据代码生成描述系统工作原理的 Markdown API 文档或 README 文件。第一章讨论了 AI 如何生成代码解释;现在正是利用这一功能的绝佳时机。
Prototypes often lack documentation, which you’ll need to add as you formalize the code: a clear, human-reviewed explanation of each module will help future team members, as well as you, when you revisit the code months later. Once you’ve cleaned up your code, you might prompt an AI tool to produce a Markdown API document or README based on the code that describes how the system works. Chapter 1 discussed how AI can produce explanations of code; this is a great moment to leverage that.
正如你在第5章中学到的,彻底测试你的原型至关重要。你可以为核心逻辑编写单元测试,为主要流程编写集成测试等等。你可以通过让人工智能生成测试用例来加快这一过程:
It’s crucial to test your prototype thoroughly, as you learned in Chapter 5. You might write unit tests for core logic, integration tests for major flows, etc. You can accelerate this by asking the AI to generate test cases:
为待办事项列表组件编写 Jest 测试,涵盖添加、编辑、完成、删除任务等功能。
Write Jest tests for the to-do list component covering adding, editing, completing, deleting tasks.
然后运行并调整它生成的测试用例。拥有完善的测试套件能让你在重构原型代码时更有信心。
Then run and adjust the tests it generates. Having a good test suite gives you confidence as you refactor the prototype code.
有时您可能需要完全替换代码的某些部分——例如,如果原型使用了某种临时搭建的库或不合适的变通方案,而这些方案从长远来看并不适用。人工智能也能加速这一过程。假设您的原型代码使用本地数组存储数据,但现在您需要一个完善的数据库集成。您可能会收到类似这样的提示:
Sometimes you might decide to replace certain sections of your code entirely—such as if the prototype used some quick-and-dirty library or a hack that isn’t suitable in the long term. AI can speed this up as well. Suppose your prototype code uses local arrays for data, but now you need a proper database integration. Your prompt might be something like this:
使用 SQLite 数据库存储任务,而不是使用内存数组。
Integrate an SQLite database for storing the tasks instead of an in-memory array.
人工智能可以为这种整合提供一个起点,然后你应该对其进行完善。
The AI can provide a starting point for this integration, which you should then refine.
在进行这些改变时,明智的做法是将你的思维方式从“快速原型模式”转变为更严谨的工程方法。现在,人工智能不再只是快速生成功能,而是成为您提升代码质量的助手。其运作方式略有不同:鉴于稳定性和质量是您的首要任务,您可能会更加严格地评估人工智能提出的每一项建议。正如我在第四章中提到的,资深开发人员可以从人工智能中获益匪浅,因为他们知道哪些建议可以接受,哪些需要改进。在这个阶段,您将充分运用这种资深开发人员的思维模式:您对最终系统已有了清晰的愿景,因此您可以委托人工智能进行具体的改进或实现。
In making these changes, it’s wise to switch your mindset from “rapid prototyping mode” to a more disciplined engineering approach. The AI is now your assistant in improving code quality—it’s no longer just spitting out quick features. The dynamic is a bit different: you might evaluate each AI suggestion more critically now that stability and quality are your top priorities. As I mentioned back in Chapter 4, senior developers can derive enormous benefit from AI because they know what to accept and what to fix. At this stage, you’ll be exercising that senior mindset heavily: you have a vision of the final system, so you task the AI with specific improvements or implementations.
为了更好地理解这个讨论,我们来看一个简单的例子。假设有一位名叫简的独立开发者,她想开发一个小型Web应用程序,将CSV文件中的数据转换成图表。她利用人工智能助手,仅用一个周末就快速完成了一个原型:一个带有 API 的基本 Node.js 脚本,以及一个简单的前端,用于上传 CSV 文件并使用 JavaScript 图表库渲染图表。
To ground this discussion, let’s consider a brief example. Imagine a solo developer, Jane, who wants to build a small web app that converts data from CSV files into charts. She uses an AI assistant to get a quick prototype done in just one weekend: a basic Node.js script with an API, plus a simple frontend to upload CSVs and render charts using a JavaScript chart library.
她向几位潜在用户演示了这个原型,并得到了积极的反馈,于是简决定将其转化为真正的产品(一项网络服务)。以下是她如何完成这一转变的:
She demonstrates this prototype to a few potential users and gets positive feedback, so Jane decides to turn it into a real product (a web service). Here’s how she navigates the transition:
原型机的 Node.js API 没有身份验证(任何人都可以上传数据)。在生产环境中,她需要用户账户和身份验证。她利用人工智能集成了一个身份验证系统(可能基于 JWT)。人工智能提供了一个框架,但她会仔细审查,以确保密码哈希处理正确且令牌安全。她还为上传端点添加了输入验证(人工智能没有做这一步),结合了人工智能建议的代码和她自己的一些调整。
The prototype’s Node.js API had no authentication (anyone could upload data). For production, she needs user accounts and auth. She uses the AI to integrate an authentication system (maybe JWT-based). The AI provides a scaffold, but she carefully reviews it to ensure passwords are hashed properly and tokens are secure. She also adds input validation to the upload endpoint (the AI had not done that), using a combination of AI-suggested code and her own tweaks.
最初的前端是一个包含脚本的单个 HTML 文件。 标签指向依赖项的 CDN。为了便于维护,Jane 决定将项目重构为结构化的 React 应用。她首先请求 AI 重构项目,使其更适合生产环境,方法是使用构建系统和 npm 而不是 script 标签。然后,她请求 AI 帮助将这些组件集成到 React 中。例如,AI 将原型中的图表渲染代码转换为<Chart>组件。Jane 利用 AI 加快了这些组件的编写速度,但她确保状态管理和组件层级遵循最佳实践(这是原型中没有深入考虑的)。
The initial frontend was a single HTML file with script tags pointing at a CDN for dependencies. Jane decides to refactor into a structured React app for maintainability. She first asks the AI to refactor her project to be more production-ready by using a build system and npm rather than script tags. She then asks the AI to help integrate them as React components. For example, it turns the chart-rendering code from the prototype into a <Chart> component. Jane uses the AI to expedite writing these components, but she ensures that the state management and component hierarchy follow best practices (something the prototype didn’t consider deeply).
Jane writes unit tests for critical functions (CSV parsing, data transformation). When she’s unsure about edge cases, she queries the AI:
CSV解析应该测试哪些极端情况?
What edge cases should I test for CSV parsing?
它提示了一些可能出现的问题,例如空字段和不规则列,她将这些问题纳入了测试中。她还注意到,原型会将整个 CSV 文件加载到内存中;对于大型文件,这可能会导致崩溃。她修改了代码,使其以流式方式处理文件,并使用 AI 来复核流式逻辑。现在,该应用程序可以更可靠地处理更大的文件。
It suggests scenarios like empty fields and irregular columns, which she incorporates into her tests. She also notices that the prototype loaded entire CSV files into memory; for large files, this could crash. She modifies the code to stream the processing and uses AI to double-check her stream logic. Now the app can handle bigger files more reliably.
原型用户界面以实用性为主。简在产品用户体验方面投入了更多精力。她让AI推荐响应式布局,并考虑集成CSS框架。AI添加了Bootstrap,她随后利用Bootstrap改进了外观(表单、按钮、布局)。之后,她又手动微调了一些CSS。这个润色阶段与其说是编写大量代码,不如说是进行设计选择,但AI仍然能够提供帮助,为标准UI模式(例如导航栏和加载指示器)提供快速代码。
The prototype UI was utilitarian. For her product, Jane spends a bit more time on user experience. She asks the AI to recommend a responsive layout and perhaps integrate a CSS framework. The AI adds Bootstrap, which she then uses to improve the look (forms, buttons, layout). She manually fine-tunes some CSS afterward. This polishing stage is less about heavy coding and more about design choices, but AI still helps by providing quick code for standard UI patterns (like a navigation bar and a loading spinner).
经过这些努力,原本粗糙的原型已经变成了一个更加简洁、安全且更具可扩展性的应用程序,可以交付给真正的用户。简信心满满地部署了它,因为她添加了测试并审查了人工智能生成的代码。从原型到正式上线的整个过程可能只用了她几周时间,而从零开始编写整个产品则需要更长的时间。人工智能加速了初始原型的开发,并在过渡过程中持续提供帮助,但简的人工监督和代码重构对于达到正式上线质量至关重要。
After these efforts, the once-rough prototype is a far cleaner, more secure, and more scalable application ready for real users. Jane deploys it, feeling confident because she added tests and reviewed the AI-generated code. This process from prototype to production might have taken her a couple of weeks, whereas writing the entire product from scratch would have taken much longer. The AI accelerated the initial prototype and continued to assist in the transition, but Jane’s human oversight and restructuring were indispensable in reaching production quality.
虽然人工智能驱动的原型设计功能强大,但它也并非没有挑战。作为开发人员,您应该了解这些问题并知道如何缓解它们。其中两个特别值得关注的领域是范围蔓延和集成。
While AI-driven prototyping is powerful, it’s not without challenges. As a developer, you should be aware of these and know how to mitigate them. Two areas of particular interest are scope creep and integration.
因为添加起来非常容易使用人工智能功能时,你可能会忍不住不断地添加“更多功能”到原型中。这种现象被称为范围蔓延。它会导致原型不断膨胀,最终沦为最终产品。记住原型的目的:专注于你想解答的关键问题或要展示的核心体验。如果你发现自己在原型阶段实现了登录系统、支付处理等功能,请问问自己这些功能是否真的必要。最好先用占位符代替(人工智能可以生成一个虚假的登录流程,仅用于模拟)。保持原型的专注性可以节省时间,也便于后续的修改或重做。
Because it’s so easy to add features with AI, you might be tempted to keep going and going, adding “one more thing” to the prototype, a phenomenon known as scope creep. This can lead to an ever-growing prototype that tries to be the final product. Remember the purpose of a prototype: to focus on the key question you want to answer or the core experience to demonstrate. If you find yourself implementing login systems, payment processing, etc., ask if that’s really needed at the prototype stage. It might be better to stub those out (the AI can generate a fake login flow that isn’t real, just to simulate it). Keeping the prototype focused will save you time and make it easier to throw away or rework later.
写下你的原型目标(例如“演示用户可以上传 CSV 文件并获取图表以测试可行性”),并将其作为前进的方向。利用人工智能快速达成目标,并抵制过度美化的诱惑。
Write down the goal of your prototype (“Demonstrate that users can upload a CSV and get a chart to test viability”), and use that as a North Star. Use the AI to get to that goal quickly, and resist the allure of gold-plating the prototype.
其次,还有与实际系统集成的问题。原型通常使用模拟数据或简化的子系统。如果你的 AI 原型使用虚拟数据或本地文件,那么将其与生产环境中的真实数据库或服务集成可能并非易事。在原型设计阶段,务必注意可能存在的简化之处。例如,原型邮件可能并未实际发送,而只是记录到控制台。在生产环境中,你需要一个真正的邮件服务。AI 可以在后续阶段协助集成这些服务,但最好在原型设计阶段就做好记录:维护一份“如果我们继续推进项目,需要解决的问题”清单。这样你就不会忘记哪些部分是临时的。如果是团队合作,一定要清楚地沟通这些临时部分。例如,你可以在代码中添加注释:。许多人工智能工具在生成简化解决方案时,实际上也会自动添加此类待办事项注释,这很有帮助。// TODO: integrate real email service here
Second, there’s the question of integration to real systems. Prototypes often use mock data or simplified subsystems. If your AI prototype uses dummy data or a local file, integrating it with real databases or services in production can be nontrivial. Be mindful when prototyping that some shortcuts were taken. For example, maybe the prototype emails weren’t actually sent but just logged to console. In production, you’ll need a real email service. The AI can help integrate those later, but it’s good to keep track: maintain a list of “things to address if we move forward” while prototyping. That way you won’t forget which parts were temporary. If working in a team, communicate these clearly. For instance, you might leave a comment in code: // TODO: integrate real email service here. Many AI tools actually include such TODO comments themselves when they generate a simplified solution, which is helpful.
通过预见这些挑战,您可以有效地利用人工智能原型设计,避免落入其陷阱。如果使用得当,就能在极短时间内开发出一个强大的原型,该原型既可以转化为最终产品,也可以在提取其提供的经验教训后搁置一旁。
By anticipating these challenges, you can use AI prototyping effectively without falling into its traps. When it is used thoughtfully, the result is a robust prototype developed in record time, ready to either be transformed into a final product or set aside after extracting the lessons it offered.
在本章中,您了解了人工智能辅助的Vibe编码如何加速原型设计流程。通过让人工智能承担繁重的代码生成工作,开发人员可以以前所未有的速度将概念转化为可运行的模型。我介绍了Vercel v0(用于UI生成)、Lovable(用于全栈原型)以及Cursor和Windsurf等人工智能增强型IDE——它们各自支持快速原型设计的不同方面。我还强调了人工智能原型设计的迭代特性:在自然语言提示的引导下,快速循环地生成、测试和改进原型。
In this chapter, you saw how AI-assisted vibe coding turbocharges the prototyping process. By letting AI handle the heavy lifting of code generation, developers can move from concept to working model with unprecedented speed. I covered tools like Vercel v0 for UI generation, Lovable for full stack prototypes, and AI-augmented IDEs like Cursor and Windsurf—each enabling different aspects of rapid prototyping. I also emphasized the iterative nature of AI prototyping: generating, testing, and refining in quick cycles, with natural-language prompts guiding the changes.
虽然人工智能驱动的原型设计可以在数小时内生成功能演示,但我们也讨论了向生产环境过渡的关键环节。信息很明确:原型并非最终产品,它只是初稿。开发人员必须重构并强化代码,而人工智能则继续协助完成这一过程(例如提出改进建议、生成测试等)。使用这些技术的个人和团队的案例研究突显了生产力的显著提升——原型构建时间从数周缩短至数天,从而能够更快地获得用户反馈并做出业务决策。
While AI-driven prototyping can produce a functional demo in hours, we also discussed the critical transition to production. The message is clear: a prototype is not a final product. It’s the first draft. Human developers must refactor and harden the code, with AI continuing to assist in that journey (suggesting improvements, generating tests, etc.). Case studies of individuals and teams using these techniques highlight the real productivity gains—prototypes built in days instead of weeks, enabling faster user feedback and business decisions.
现在你应该已经体会到,氛围式编码让原型设计更像是与助手进行头脑风暴,而不是枯燥地编写样板代码。这是一种截然不同的氛围:更像对话,更注重高层次的思考,而且速度更快。然而,你也已经意识到,即使在快速原型阶段,保持代码质量意识也至关重要——尤其是在原型阶段之后进行迭代开发时。
By now, you should appreciate how vibe coding makes prototyping feel more like brainstorming with an assistant rather than grinding out boilerplate. It’s a fundamentally different vibe: more conversational, more high-level, and a lot faster. However, you’ve also seen the importance of maintaining code quality awareness even in a quick prototype—and definitely when evolving it beyond the prototype stage.
在第七章中,我将把重点从快速原型开发转移到借助人工智能辅助的全面Web应用程序开发。原型开发旨在探索各种可能性,而全面开发则需要系统化的架构、实现和部署方法。
In Chapter 7, I’ll shift focus from rapid prototyping to comprehensive web application development with AI assistance. While prototyping explores possibilities, full-scale development demands systematic approaches to architecture, implementation, and deployment.
本章将重点从快速创建原型转移到使用人工智能辅助开发完整的 Web 应用程序。Web 应用程序通常包括前端(通常使用 React、Angular 或 Vue 等框架编写)、后端(API、数据库、服务器)以及连接所有部分的粘合剂。Vibe 编码可以加速这些层级的运行。
This chapter shifts the focus from prompting quick prototypes to developing complete web applications using AI assistance. Web apps typically involve a frontend (often written in frameworks like React, Angular, or Vue), a backend (APIs, databases, servers), and glue to connect everything. Vibe coding can accelerate each of these layers.
我将带你了解构建的完整工作流程一个包含人工智能结对编程的Web应用程序,其中包括:
I’ll walk you through an end-to-end workflow for building a web application with an AI pair programmer, including:
项目及其框架的搭建
Setting up the project and its scaffolding
编写前端用户界面代码
Coding the frontend UI
实现后端逻辑
Implementing backend logic
与数据库集成
Integrating with a database
对整个技术栈进行测试和验证。
Testing and validating the whole stack
在本章中,我将重点介绍前端(例如,让 AI 根据描述生成 React 或 Vue 组件)和后端(通过自然语言提示编写路由、业务逻辑和数据库查询)的 AI 开发模式。我还会讲解如何在全栈项目中优化人机协作,确保双方都能发挥各自的优势。读完本章后,您应该能够清晰地了解如何利用 AI,不仅将其用于孤立的编码任务,还能高效地管理整个 Web 开发工作流程。
Along the way, I’ll highlight AI development patterns for frontends (for example, having AI generate React or Vue components from descriptions) and backends (writing routes, business logic, and database queries through natural-language prompts). I’ll also cover how to optimize collaboration between humans and AI in a full stack project, ensuring that each side contributes its strongest work. By the end of this chapter, you should have a clear roadmap for using AI not just for isolated coding tasks but for managing entire web development workflow efficiently and effectively.
每个 Web 应用程序都是从一些脚手架开始的——构建工具、文件结构、依赖项等的初始设置。人工智能可以自动生成大量样板代码。现代 Web 框架通常自带命令行界面 (CLI) 工具,可以生成基础项目,但您可能仍然需要配置某些内容或集成其他库。人工智能助手可以提供帮助,既可以指导您使用这些 CLI 工具,也可以根据需要设置自定义项目结构。
Every web application starts with some scaffolding—the initial setup of build tools, file structure, dependencies, etc. AI can automate the creation of a lot of the boilerplate. Modern web frameworks often come with command-line interface (CLI) tools that can generate a base project, but you might still need to configure certain things or integrate additional libraries. An AI assistant can help by either guiding you through these CLI tools or setting up custom project structures on demand.
例如,假设你想用 React 作为前端,Express 作为后端,创建一个新的应用程序项目。在人工智能出现之前,完成这项任务的工作流程可能如下所示:
For example, suppose you want to start a new application project using React for the frontend and Express for the backend. A pre-AI workflow for this task would probably look something like this:
运行 CLI 工具或 Vite 来设置 React 项目。
Run a CLI tool or Vite to set up the React project.
初始化一个 Express 应用(可能需要npm init安装 Express)。
Initialize an Express app (perhaps with npm init and installing Express).
设置开发代理或配置跨域资源共享 (CORS),以便 React 前端可以与 Express 后端通信。
Set up a proxy for development or configure Cross-Origin Resource Sharing (CORS) so the React frontend can talk to the Express backend.
或许可以集成像 MongoDB 这样的数据库,或者为了方便使用而设置一个 SQLite 文件。
Maybe integrate a database like MongoDB or set up an SQLite file for simple usage.
使用 Cursor 或 Cline 等 AI 编码环境,您可以一次性描述所需的设置:
Using an AI coding environment like Cursor or Cline, you can instead describe your desired setup in one go:
创建一个新项目,前端使用 React(使用 Vite),后端使用 Express。后端应提供待办事项列表的 REST API,并使用内存数组启动。在开发环境中,配置前端将 API 请求代理到后端。
Set up a new project with a React frontend (using Vite) and an Express backend. The backend should serve a REST API for a to-do list and use an in-memory array to start. Configure the frontend to proxy API requests to the backend in development.
高级人工智能集成开发环境(IDE)可以接收此指令并执行以下操作:
An advanced AI IDE can take this instruction and do the following:
创建两个目录(前端和后端)。
Create two directories (frontend and backend).
运行npm create vite@latest(如果具有 shell 访问权限)或创建基本 React 应用程序模板。
Run npm create vite@latest (if it has shell access) or template out a basic React app.
在后端初始化一个基本的 Express 服务器文件,其端点类似于/api/to-dos(返回一些示例数据)。
Initialize a basic Express server file in the backend, with an endpoint like /api/to-dos (returning some sample data).
在每个目录中包含一个package.json 文件,其中包含相关的脚本(例如start both)。
Include a package.json in each directory with relevant scripts (like start both).
通过在 React 开发服务器中配置代理或提供 CORS 标头的实现说明,建立前端和后端之间的通信。
Set up communication between frontend and backend by either configuring a proxy in the React development server or providing instructions for implementing CORS headers.
几分钟之内,你就能搭建出一个完整的 Web 应用框架。即使 AI 不能完全自动完成所有操作,它也会为你提供代码以及完成应用所需的说明(例如,“将此代理设置添加到你的 React package.json文件中”)。这可以节省大量繁琐的设置时间,让你立即专注于功能开发。
Within a couple of minutes, you’ll have the skeleton of a full stack web app. Even if the AI doesn’t do everything automatically, it might present you with code and the instructions you need to finalize it (for example, “Add this proxy setting to your React package.json file”). This saves a lot of mindless setup time and allows you to focus immediately on features.
如果您未使用 AI IDE,您仍然可以逐步使用 ChatGPT 或其他助手;例如:
If you aren’t using an AI IDE, you can still use ChatGPT or another assistant step-by-step as you go; for example:
我想创建一个新的 React 应用。我应该运行哪些命令?
I want to create a new React app. What commands should I run?
人工智能可以引导您完成步骤,或者推荐更新的替代方案,例如 Vite 或 Next.js:
The AI can guide you through steps or recommend newer alternatives like Vite or Next.js:
现在设置一个带有 /api/to-dos 路由的 Express 服务器。
Now set up an Express server with a /api/to-dos route.
它可以生成 Express 服务器的代码,您可以将其复制到一个文件中:
It can generate the code for the Express server, which you copy into a file:
开发过程中,如何将我的 React 应用连接到这个 API?
How do I connect my React app to this API during development?
它可能建议进行代理配置,或者告诉你如何调用 API(如果不使用代理,则包括完整的 URL)。
It might suggest either a proxy configuration or tell you how to call the API (including the full URL, if not proxying).
这样一来,就连搭建基本的基础设施也变成了一场对话,而不是翻阅文档。正如前几章所述,意图编程意味着你告诉人工智能你想要的结果,它会帮你找出实现步骤。项目搭建正是这种编程方式的完美应用场景。
This way, even setting up the basic plumbing becomes a conversation rather than a hunt through documentation. As noted in earlier chapters, programming by intent means you tell the AI what outcome you want, and it figures out the steps. Setting up a project is a perfect scenario for that.
在这个阶段,明确你的架构决策至关重要。人工智能会遵循你的指示。人类在架构和高层决策中起着不可或缺的作用,因此请自行决定技术栈和主要模式:你想要单体仓库还是前后端分开的仓库?你会使用 REST 还是 GraphQL?使用哪个数据库?
At this stage, it’s important to assert your architectural decisions. The AI will follow your lead. Humans are essential for architectural and high-level decisions, so decide on the stack and major patterns yourself: Do you want a monorepo or separate repos for front and back? Will you use REST or GraphQL? Which database?
一旦你明确了这些,就可以据此指示人工智能:
Once you have these in mind, you can instruct the AI accordingly:
同时为 SQLite 数据库设置了一个基本的 Prisma 模式。
Also set up a basic Prisma schema for the SQLite database.
或者:
Or:
使用 GraphQL 服务器代替 REST 服务器。
Include a GraphQL server instead of REST.
人工智能可能无法完美地执行复杂的设置,但它可以完成大部分工作,你可以在此基础上进行改进。
The AI might not perfectly execute complex setups, but it will get the bulk of the work done, and you can refine from there.
许多经验丰富的开发者会将这些步骤集成到项目模板中,或者使用样板生成器,但人工智能提供了一种更灵活的方法:您可以使用自然语言即时进行自定义。这意味着,如果您的项目略有不同(例如,您需要三个服务而不是通常的两层架构,或者您想要预先配置某个特定的库,例如 Tailwind CSS),只需告诉人工智能您想要的内容即可。
Many experienced developers integrate these steps into project templates or use boilerplate generators, but AI offers a more flexible approach: you can customize on the fly using natural language. This means if your project is slightly unusual (maybe you need three services instead of the usual two tiers, or you want to preconfigure a particular library like Tailwind CSS), just ask the AI to include what you want.
一旦框架搭建完成,开发 Web 应用程序的前端就是大部分工作。 本节探讨如何利用人工智能结对程序员来编写前端代码。
Once the scaffolding is ready, developing the frontend of a web app is a major part of the effort. This section explores how you can leverage an AI pair programmer for your frontend code.
You can ask the AI to create components by describing their functionality and appearance; for example:
创建一个名为 TodoList 的 React 组件,该组件接收一个待办事项列表并显示它们。每个事项应显示其标题和一个用于标记其是否已完成的复选框。
Create a React component called TodoList that takes a list of to-do items and displays them. Each item should show its title and a checkbox to mark it complete.
AI 应该生成一个功能组件形式的代码,并根据需要添加 props 和 state:
The AI should produce the code as a functional component, with props and state as needed:
创建一个 Vue 组件作为登录表单,包含用户名和密码输入框,并在提交时发出包含表单数据的事件。
Create a Vue component for a login form with inputs for username and password, and emit an event with the form data on submit.
AI 可能会相应地输出 `<head> <template>`、<script>`<body>` 和<style>`<body>` 部分。作为开发者,您无需编写样板代码,即可直接获得所需的结构。如有需要,也很容易进行调整。通常,如果您的提示表明需要,AI 甚至还会包含基本的验证或状态处理功能。
The AI will likely output the <template>, <script>, and <style> sections accordingly. You, as the developer, skip writing boilerplate and directly get the structure you need. It’s then easy to tweak if needed. Often the AI will even include basic validation or state handling, if your prompt implies that they’re needed.
在这个阶段,保持一致性至关重要。如果您单独生成多个组件,则可能需要调整它们才能协同工作。例如,如果某个TodoList组件期望物品具有特定的形状,请确保所有使用该形状的组件都TodoList提供该形状。您可以选择在一个提示中生成所有组件(以便 AI 了解所有内容),或者自行连接它们,然后让 AI 修复任何不匹配之处。
It’s important to ensure consistency at this stage. If you generate multiple components in isolation, you might need to adjust them to work together. For instance, if the TodoList expects items as a certain prop shape, make sure any component that uses TodoList provides that. You can either generate components in one prompt (so the AI is aware of everything) or simply wire them up yourself and ask the AI to fix any mismatches.
CSS和样式可能很乏味。请描述 你想要的造型,然后……AI负责处理CSS细节:
CSS and styling can be tedious. Describe the look you want and let the AI handle the CSS details:
为待办事项列表组件设置样式:使用弹性列作为列表,添加一些间距,并将已完成项目的文本颜色更改为灰色并划掉。
Style the to-do list component: use a flex column for the list, add some spacing, and change the text color of completed items to gray and crossed out.
对于登录表单组件,将其居中放置在页面上,并将输入字段放大,并添加圆角边框。
For the login form component, center it on the page and make the input fields larger with rounded borders.
根据上下文,该助手可以输出 CSS-in-JS、纯 CSS 或内联样式。如果您使用的是 Tailwind CSS 之类的框架,甚至可以要求它输出相应的类(但请记住,并非所有模型都完全了解 Tailwind )。
The assistant can output CSS-in-JS, plain CSS, or inline styles, depending on context. If you’re using a framework like Tailwind CSS, you could even ask it to output the appropriate classes (though keep in mind that not all models know Tailwind thoroughly).
关键在于:你可以迭代设计而无需手动调整 CSS 值。这使你的注意力集中在更高的抽象层面上——指定什么看起来美观,而不是编写每一个 `<style>`margin和 `<style>`属性color。
The point is: you can iterate on design without manually fiddling with CSS values. This keeps your focus at a higher level of abstraction—specifying what looks good rather than writing every margin and color.
Web 前端经常需要从后端获取数据,并使用 Redux、上下文或简单的组件状态等来管理状态。人工智能可以帮助编写这些整合部分;例如:
Web frontends often need to fetch data from backends and manage state with something like Redux, context, or simple component state. AI can help write these integration pieces; for example:
添加代码,在组件挂载时从 /api/to-dos 获取待办事项列表TodoList,并将其存储在状态中。
Add code to fetch the to-do list from /api/to-dos when the TodoList component mounts, and store it in state.
实现一个函数TodoList,当复选框切换时,POST向/api/to-dos/{id}/complete发送请求,然后相应地更新状态。
Implement a function in the TodoList that, when a checkbox is toggled, sends a POST request to /api/to-dos/{id}/complete and then updates the state accordingly.
AI 可以生成useEffectReact 中的 hook 来进行 fetch 操作,也mounted()可以生成 Vue 中的 hook。它还可以模拟 HTTP 调用(使用fetchAxios 等工具)。你需要确认 API 端点和有效负载与后端预期相符(如果你已经构建了后端或有后端规范)。
The AI can generate the useEffect hook in React to do the fetch or the mounted() hook in Vue. It can also stub out the HTTP calls (using fetch or Axios, etc.). You’ll want to confirm that the API endpoints and payloads match what your backend expects (if you’ve built the backend or have a spec for it).
如果你还没有构建后端,你可能正在同时使用人工智能来创建它——我们稍后会详细介绍。但你可以借助人工智能并行开发前端和后端,因为只要你跟踪好它们之间的接口,它们就可以相对独立地进行指定和生成。
If you haven’t built the backend yet, you might simultaneously be using the AI to create it—we’ll get to that soon. But you can work on front and back in parallel with AI assistance, because each can be specified and generated relatively independently, as long as you keep track of the interface between them.
如果你的前端有复杂的逻辑,例如动态的表单验证规则、条件渲染或复杂的交互,您都可以使用 AI 逐步实现。一个好的做法是将问题分解:
If your frontend has complex logic, such as dynamic form validation rules, conditional rendering, or intricate user interactions, you can implement these step-by-step with AI. A good practice is to break the problem down:
添加一项功能:当用户选中待办事项中的“完成”复选框时,淡出该列表项(CSS 过渡效果),然后在 1 秒后将其从列表中删除。
Add a feature: when the user checks the “complete” box on a to-do, fade out that list item (CSS transition), then remove it from the list after 1 second.
人工智能可能会生成代码,在选中商品时添加 CSS 类,并使用超时机制移除该商品,包括淡出所需的 CSS:
The AI might produce the code to add a CSS class on check and use a timeout to remove the item, including the necessary CSS for fading out:
表单中有一个可选的“备注”字段。只有选中“添加备注”复选框时,才会显示备注文本区域。
The form has an optional field for ‘notes’. Only show the notes text area if an ‘Add notes’ checkbox is checked.
AI 可以修改组件状态和 JSX,从而有条件地渲染备注字段。
The AI can modify the component state and JSX to conditionally render the notes field.
这些都可以作为迭代提示。本质上,你描述用户体验行为,AI 生成代码。每次添加功能后都要进行测试,以确保其行为符合预期。
Each of these can be an iterative prompt. Essentially, you describe the UX behavior and AI writes the code. Always test after each addition to ensure it behaves as expected.
Different frameworks have different idioms:
在 React 中,AI可能会使用钩子(例如useState,useEffect)。请仔细检查它是否遵循最佳实践(例如,依赖项数组useEffect是否正确)。
In React, the AI might use hooks (like useState, useEffect). Double-check that it’s following best practices (for instance, that the dependencies array in useEffect is correct).
在 Vue 中,AI 可能会根据它所看到的内容,输出 Options API 风格或 Composition API 风格。如果您偏好使用某种方法,则应明确指出(例如,“使用 Vue 3 Composition API”)。
In Vue, the AI might output Options API style or Composition API style depending on what it has seen. If you prefer one, you should specify that (for instance, “Use Vue 3 Composition API”).
在 Angular 中,人工智能可以生成组件,但 Angular 的学习曲线更陡峭。AI 或许能够根据请求生成模板、TypeScript 类和基本服务注入,但您可能需要进行更多手动工作,或者使用 Angular CLI 来构建结构,然后让 AI 填充特定部分(例如表单验证逻辑)。
In Angular, the AI can generate components, but Angular has a steeper learning curve. The AI might be able to produce a template, a TypeScript class, and basic service injection on request, but you’ll likely need to do more manual work or use Angular CLI for structure, then ask AI to fill in specific parts (like form validation logic).
现在我们来看看后端。 使用人工智能构建 Web 应用程序的服务器端遵循类似的模式:您描述所需的端点、数据模型和逻辑,人工智能生成代码。常见的后端组件包括路由处理程序、业务逻辑、数据库交互和验证。人工智能可以协助完成所有这些工作。
Now let’s turn to the backend. Using AI to build the server side of a web application follows a similar paradigm: you describe the endpoints, data models, and logic you want, and the AI produces code. Common backend components include route handlers, business logic, database interactions, and validations. AI can help with all of these.
假设你正在建造一个RESTful API你的待办事项应用。你可能会有如下的端点GET /to-dos:POST /to-dos,,,PUT /to-dos/:id。DELETE /to-dos/:id 您可以逐个端点进行操作:
Suppose you’re building a RESTful API for your to-do list app. You might have endpoints like GET /to-dos, POST /to-dos, PUT /to-dos/:id, DELETE /to-dos/:id. You can go endpoint by endpoint:
在 Express 应用中,添加一个GET /api/to-dos返回待办事项列表的路由(目前只需使用存储在内存中的数组)。
In the Express app, add a GET /api/to-dos route that returns the list of to-dos (just use an array stored in memory for now).
添加一个POST /api/to-dos路由,该路由接受一个 JSON 请求体,并将一个新的待办事项添加到列表中。返回带有 ID 的新待办事项。
Add a POST /api/to-dos route that accepts a JSON body and adds a new to-do to the list. Return the new to-do with an ID.
AI 会据此编写 Express 路由处理程序,可能使用类似这样的方法app.get('/api/to-dos', ...)。如果您已表明您正在使用带有 JSON 的 Express,它可能会包含必要的中间件(如果尚未存在):
The AI will write the Express route handlers accordingly, likely using something like app.get('/api/to-dos', ...). If you’ve indicated that you’re using Express with JSON, it might include the necessary middleware if it’s not already present:
app.use(express.json())
app.use(express.json())
随着后端规模的增长,您可以要求 AI 进行重构:
As your backend grows, you can ask the AI to refactor:
将 Express 路由重构为一个独立的路由模块。
Refactor the Express routes into a separate router module.
它可能会将路由拆分到一个单独的文件中,这对于可维护性来说是一个很好的做法。
It might split the routes out into a separate file, which is a good practice for maintainability.
你可能会用内存这些数据可用于原型开发,但对于更完整的应用程序,您需要一个数据库。假设您选择 MongoDB 或 PostgreSQL。您可以提示:
You might use in-memory data for a prototype, but for a more complete application, you’ll want a database. Let’s say you choose MongoDB or PostgreSQL. You can prompt:
使用 Mongoose 将 MongoDB 集成到 Express 应用中。创建一个待办事项模型,包含以下字段:title(字符串)、completed(布尔值)。修改 GET/POST 路由,使其使用数据库而不是内存数组。
Integrate MongoDB into the Express app using Mongoose. Create a to-do model with fields: title (string), completed (boolean). Modify the GET/POST routes to use the database instead of an in-memory array.
AI 可以输出 Mongoose 模型定义,并调整路由处理程序以查询数据库(例如 ` Todo.find()for`GET和Todo.create()`for` POST)。类似地,对于 SQL,您可以让它设置对象关系映射(ORM),例如 Prisma 或 Sequelize。请注意,您可能需要提供配置详情(例如连接字符串)。人工智能可能不知道您的数据库 URI;您需要手动填写。但它会处理通用代码。
The AI may output the Mongoose model definition and adjust the route handlers to query the database (like Todo.find() for GET and Todo.create() for POST). Similarly, for SQL, you could ask it to set up an object-relational mapping (ORM) like Prisma or Sequelize. Keep in mind you might need to provide configuration details (like connection strings). The AI might not know your database URI; you’ll have to slot that in. But it will handle the generic code.
如果你的后端有具体的规则(例如,用户不能删除标记为重要的待办事项,或者列表标题必须唯一),您可以通过人工智能进行编码:
If your backend has specific rules (for example, that users cannot delete a to-do that is marked important or that list titles must be unique), you can encode those via AI:
为路由添加验证
POST /api/to-dos:如果标题为空或长度超过 100 个字符,则拒绝请求,并返回 400 状态码。
Add validation to the
POST /api/to-dosroute: reject if the title is empty or longer than 100 chars, and return 400 status.
人工智能将进行检查并发送适当的响应。
The AI will include checks and send proper responses.
添加逻辑:当待办事项被标记为完成(例如通过
PUT /api/to-dos/:id),如果所有待办事项都已完成,则记录消息“全部完成!”。
Add logic: when a to-do is marked complete (say via
PUT /api/to-dos/:id), if all to-dos are complete, log a message ‘All done!’
它可以将该逻辑插入到PUT处理程序中。
It can insert that logic in the PUT handler.
你用简单的语言描述这些需求,人工智能会据此修改代码。但你仍然需要测试代码是否符合预期。
You describe these requirements in plain terms, and the AI modifies the code accordingly. You still need to test that the code does what you expect.
许多 Web 后端使用框架除了原生 Express 之外(例如 Node 的 NestJS 或 Python 的 Django)。人工智能也可以处理这些任务,不过你可能需要将更复杂的任务分解开来:
Many web backends use frameworks beyond raw Express (like NestJS for Node or Django for Python). AI can work with those, too, though you may have to break down more involved tasks:
对于 Django(Python),您可能会提示:
创建一个包含字段 X 的 Django 待办事项模型,以及相应的列表和创建视图。
For Django (Python), you might prompt:
Create a Django model for to-do with fields X, and corresponding views for list and create.
如果人工智能知道上下文,它可能会输出模型代码和通用视图或 DRF(Django REST Framework)序列化器/视图集。
The AI might output model code and a generic view or DRF (Django REST Framework) serializer/viewset if it knows that context.
对于 Ruby on Rails,您可以获得生成模型和控制器的帮助。(此时,您可能只需使用 Rails 脚手架,但 AI 可以通过添加验证或调整路由来补充功能。)
For Ruby on Rails, you can get help generating models and controllers. (At that point, you might just use Rails scaffolding, but the AI could supplement by adding validations or adjusting routes).
人工智能模型在不同的编程语言和技术栈上的表现水平参差不齐,这主要取决于这些技术在其训练数据中的普及程度。虽然模型可以处理训练过程中遇到的任何语言,但它们的有效性却大相径庭。像 JavaScript、Python 和 Java 这样的流行语言通常会获得更强的支持,因为它们在开源代码库、文档和教育材料中拥有丰富的资源,而这些资源正是训练语料库的一部分。
AI models demonstrate varying levels of proficiency across different programming languages and technology stacks, largely determined by the prevalence of those technologies in their training data. While models can work with any language they’ve encountered during training, their effectiveness varies significantly. Popular languages like JavaScript, Python, and Java typically receive stronger support due to their abundant representation in open source repositories, documentation, and educational materials that form part of the training corpus.
要确定模型对所选技术栈的熟练程度,需要进行实际评估。首先,使用目标语言的基本任务测试模型,然后逐步增加任务复杂度来评估其能力。注意模型是否能生成符合语言规范的惯用代码,是否能在无需过多解释的情况下识别常用框架和库,以及是否能为该生态系统推荐合适的设计模式。强大的功能体现在能够提供上下文相关的建议,而较弱的支持往往会导致生成通用或过时的代码模式。
Determining a model’s proficiency with your chosen stack requires practical evaluation. Start by testing the model with basic tasks in your target language, then progressively increase complexity to gauge its capabilities. Pay attention to whether the model generates idiomatic code that follows language-specific conventions, recognizes common frameworks and libraries without extensive explanation, and suggests appropriate design patterns for that ecosystem. Strong proficiency manifests as contextually appropriate suggestions, while weaker support often results in generic or outdated code patterns.
许多人工智能提供商都会发布关于其模型功能的文档,但这些文档很少包含针对特定语言的详细基准测试。最可靠的方法是使用您实际的技术栈运行小型实验。例如,如果您使用的是 Ruby on Rails,请测试模型是否理解 Rails 的约定(例如 ActiveRecord 模式)或能否生成正确的 RSpec 测试。同样,对于较新的框架或不太常用的语言,预计结果会更加不稳定,并且需要准备好在提示中提供额外的上下文信息,以弥补模型训练中可能存在的不足。
Many AI providers publish documentation about their models’ capabilities, though these rarely include detailed language-specific benchmarks. The most reliable approach involves running small experiments with your actual technology stack. For instance, if you’re working with Ruby on Rails, test whether the model understands Rails conventions like ActiveRecord patterns or can generate proper RSpec tests. Similarly, for newer frameworks or less common languages, expect more variable results, and be prepared to provide additional context in your prompts to compensate for potential gaps in the model’s training.
有些端点可能涉及多个步骤,例如在一个表中创建条目,然后再在另一个表中创建条目,或者调用外部 API。你可以大致勾勒出流程,然后让人工智能来生成:
Some endpoints might involve multiple steps, like creating an entry in one table and then another, or calling an external API. You can outline the sequence and let the AI draft it:
当新用户注册时(
POST /api/users),创建用户记录,并通过 SendGrid API 发送欢迎电子邮件。
When a new user signs up (
POST /api/users), create a user record and also send a welcome email via SendGrid API.
人工智能可以编写代码节省 用户(可能使用对象关系映射器,或 ORM)然后是 HTTP 使用适当的有效负载向 SendGrid 的 API 发送请求。您需要填写实际的 API 密钥或调整内容,但大部分样板工作已经完成:
The AI can write code to save the user (maybe using an object-relational mapper, or ORM) and then an HTTP request to SendGrid’s API with appropriate payload. You’d fill in actual API keys or tweak content, but most of the boilerplate is done:
实现交易:转账时
POST /api/transfer,从账户 A 扣除金额并添加到账户 B,确保它是原子性的(要么全有,要么全无)。
Implement a transaction: when transferring money (
POST /api/transfer), deduct from account A and add to account B, ensure it’s atomic (all-or-nothing).
如果你正在使用 ORM 或数据库,那么如果人工智能支持事务,它可能会使用这些特性(例如 SQL 事务块或 ORM 的事务方法)。务必仔细审查此类代码的正确性——事务逻辑尤其复杂。但人工智能可能了解常见的陷阱并包含相应的检查。例如,当被要求处理转账端点时,人工智能生成了以下代码结构:
If you’re using an ORM or database that supports transactions, the AI might use those features (like an SQL transaction block or an ORM’s transaction method). Review such code cautiously for correctness—transaction logic, especially, can be tricky. But the AI might know common pitfalls and include checks. For instance, when prompted to handle a money transfer endpoint, an AI generated the following code structure:
```async function transferMoney(fromAccountId, toAccountId, amount) {const session = await db.startSession();try {await session.startTransaction();// Deduct from source accountconst sourceAccount = await Account.findByIdAndUpdate(fromAccountId,{ $inc: { balance: -amount } },{ session, new: true });if (sourceAccount.balance < 0) {throw new Error('Insufficient funds');}// Add to destination accountawait Account.findByIdAndUpdate(toAccountId,{ $inc: { balance: amount } },{ session });await session.commitTransaction();return { success: true };} catch (error) {await session.abortTransaction();throw error;} finally {session.endSession();}}```
```async function transferMoney(fromAccountId, toAccountId, amount) {const session = await db.startSession();try {await session.startTransaction();// Deduct from source accountconst sourceAccount = await Account.findByIdAndUpdate(fromAccountId,{ $inc: { balance: -amount } },{ session, new: true });if (sourceAccount.balance < 0) {throw new Error('Insufficient funds');}// Add to destination accountawait Account.findByIdAndUpdate(toAccountId,{ $inc: { balance: amount } },{ session });await session.commitTransaction();return { success: true };} catch (error) {await session.abortTransaction();throw error;} finally {session.endSession();}}```
该人工智能正确地将两个数据库操作都封装在事务中,包含了资金不足的验证,并妥善处理了任何错误时的回滚。虽然您仍然需要审查一些特殊情况并添加相应的日志记录,但基本的事务结构表明它理解原子操作。
The AI correctly wrapped both database operations in a transaction, included validation for insufficient funds, and properly handled rollback on any error. While you’d still need to review edge cases and add appropriate logging, the fundamental transaction structure demonstrates understanding of atomic operations.
构建 API 时,还可以让 AI 生成文档。例如,“为 /api/to-dos 端点编写一份简短的文档。”它可能生成类似这样的内容:
When building APIs, you can also have the AI produce documentation. For instance, “Write a brief documentation for the /api/to-dos endpoints.” It may generate something like this:
GET /api/to-dos - 返回待办事项列表。
POST /api/to-dos - 创建新的待办事项。预期 JSON 格式:{title: string}。返回创建的待办事项。
...GET /api/to-dos - returns list of to-dos.
POST /api/to-dos - create a new to-do. Expects JSON: {title: string}. Returns the created to-do.
...
这便于快速参考,也可以与前端开发人员共享(如果您在团队中工作)。此外,您还可以使用 AI 为 API 端点编写测试,例如使用 Jest 或 Mocha 等 Node 测试框架,或者使用 PyTest 等 Python API 测试框架。只需输入类似“为待办事项 API 生成测试(一个用于列出待办事项,一个用于创建待办事项,一个用于验证错误)”的提示,AI 就会输出您可以运行和验证的测试代码。
This is handy for quick reference and also to share with frontend developers (if you’re working in a team). Additionally, you can use AI to write tests for your API endpoints, using a testing framework like Jest or Mocha for Node, or PyTest for a Python API. With a prompt like “Generate tests for the to-dos API (one test for listing, one for creating, one for validation error),” the AI will output test code that you can run and verify.
人类对业务的了解域名是人工智能在数据库模式设计中至关重要,它还可以辅助将设计转化为代码(例如迁移脚本或 ORM 模型)。此外,如果您对数据库模式不确定,还可以借助人工智能进行头脑风暴。
Human knowledge of the business domain is crucial in designing a database schema, but AI can assist in translating that design into code (like migration scripts or ORM models). Also, if you’re unsure about your schema, you can brainstorm with the AI.
例如,假设你的应用正在从待办事项列表扩展到完整的项目管理工具。你需要设计多个表:项目、任务、用户等等。你可以问:“对于一个包含用户、项目和任务的简单项目管理应用,我需要什么样的数据模型?包括它们之间的关系。” 人工智能可能会给出类似这样的回答:
For example, say your app is expanding beyond to-do lists to become a full project-management tool. You need to design several tables: Projects, Tasks, Users, and so on. You could ask, “What data models would I need for a simple project management app with users, projects, and tasks? Include relationships.” The AI might respond with something like this:
用户(ID、姓名、电子邮件等)
User (id, name, email, etc.)
项目(id、名称、引用用户的 owner_id)
Project (id, name, owner_id referencing User)
任务(id、描述、项目id、分配给(用户)、状态等)
Task (id, description, project_id, assigned_to (User), status, etc.)
这可能并非完全符合你的预期,但它能为你提供一个起点。你可以确认或调整这些设计理念,然后付诸实施。
It might not be exactly what you want, but it gives you a starting point. You confirm or tweak these design ideas, then implement them.
如果你使用像 Prisma 或 Entity 这样的 ORM 工具。框架或 SQLAlchemy,可以让 AI 生成模型。类或模式定义:
If you use an ORM like Prisma, Entity Framework, or SQLAlchemy, you can have the AI generate model classes or schema definitions:
使用 Sequelize(适用于 Node),定义用户、项目、任务模型及其关联关系:一个用户可以有多个项目,项目属于该用户;项目可以有多个任务,任务属于该项目;任务可以分配给一个用户(多对一)。
Using Sequelize (for Node), define models for User, Project, Task with associations: One User has many Projects, Project belongs to User; Project has many Tasks, Task belongs to Project; Task can be assigned to a User (many-to-one).
然后,人工智能会编写 JS/TS 代码来定义这些 Sequelize 模型和关联关系,您可以将其集成到您的代码库中。如果它熟悉外键或级联规则,还可能会建议使用它们。
The AI would then write JS/TS code to define those Sequelize models and associations, which you can then integrate into your codebase. It might also suggest foreign keys or cascade rules if it’s familiar with them.
如果你没有使用 ORM,并且你编写原始 SQL 迁移脚本时,甚至可以让 AI 生成迁移脚本:
If you aren’t using an ORM and you’re writing raw SQL migrations, you could even have the AI draft migration scripts:
编写 SQL 脚本,创建用户表、项目表、任务表,并添加适当的外键。
Write an SQL script to create tables for users, projects, tasks with appropriate foreign keys.
它将输出一个 SQL DDL 脚本,您可以检查其正确性并运行它。
It will output an SQL DDL script, which you can review for correctness and run.
在代码中集成数据库时,您可能需要比简单的 CRUD 操作更复杂的查询。假设你想获取所有项目,以及它们的任务和分配给每个任务的用户——这需要跨 Project、Task 和 User 进行连接。你可以这样提示:
When integrating the database in your code, you might need queries more complex than simple CRUD. Suppose you want to get all projects, along with their tasks and the user assigned to each task—that’s a join across Project, Task, User. You could prompt:
编写 SQL 查询语句,检索项目及其任务,以及每个任务分配的用户名。
Write an SQL query to retrieve projects with their tasks and each task’s assigned user name.
人工智能可以为你生成 SQL 连接查询。
The AI could produce an SQL join query for you.
或者,如果您正在使用 ORM:
Or if you’re using an ORM:
使用 Sequelize 获取所有项目及其关联的任务,以及每个任务的用户。
Using Sequelize, fetch all projects with associated tasks and the user for each task.
您可以预期代码中会包含一些用于加载相关数据的功能,例如:
You could expect the code to come with something to load related data, like:
包含:[任务,{模型:用户,作为:'assignedUser'}]include: [Task, { model: User, as: 'assignedUser' }]
数据库操作需要仔细验证以确保AI生成的代码与您的实际数据库模式保持一致,并维护数据完整性。除非您在提示中明确提供,否则AI无法自动识别具体的表名、字段名或字段关系。即使模型具备对话记忆功能,您也应该在每个涉及复杂数据库的提示中包含数据库模式的详细信息,以确保准确性。这种明确的方法可以避免AI生成的查询引用通用字段名(例如,user_id当您的数据库模式实际使用`table`userId或`field`时)的常见问题customer_ref。
Database operations require careful verification to ensure the AI-generated code aligns with your actual schema and maintains data integrity. The AI cannot automatically know your specific table names, field names, or relationships unless you provide this information explicitly in your prompt. Even when models have conversation memory, you should include schema details in each complex database-related prompt to ensure accuracy. This explicit approach prevents the common issue of AI-generated queries that reference generic field names like user_id when your schema actually uses userId or customer_ref.
绩效考量往往需要人工监督。虽然人工智能模型能够理解主键和连接等基本数据库概念,但它们可能不会自动建议性能优化措施,例如在常用字段上添加索引或考虑查询执行计划。因此,需要审查生成的查询语句的效率,特别是那些频繁运行或针对大型数据集的操作。
Performance considerations often require human oversight. While AI models understand basic database concepts like primary keys and joins, they may not automatically suggest performance optimizations such as adding indexes on frequently queried fields or considering query execution plans. Review generated queries for efficiency, particularly for operations that will run frequently or against large datasets.
数据一致性规则是另一个关键领域。需要明确指定。在实现删除操作时,请清晰定义您预期的级联行为。例如,删除Project记录时,您必须决定数据库是否应Task通过级联删除自动删除关联记录,还是应由应用程序逻辑处理此清理工作。务必将这些业务规则清晰地传达给人工智能:
Data consistency rules represent another critical area requiring explicit specification. When implementing delete operations, clearly define the cascading behavior you expect. For example, when deleting a Project record, you must decide whether the database should automatically delete associated Task records through cascading deletes or whether your application logic should handle this cleanup. Communicate these business rules clearly to the AI:
当项目被删除时,配置数据库以级联删除所有相关任务。
When a project is deleted, configure the database to cascade delete all related tasks.
或者:
Or alternatively:
删除项目时,先检查是否存在现有任务,如果存在,则阻止删除。
When deleting a project, first check for existing tasks and prevent deletion if any exist.
只要给出明确的指示,人工智能就能有效地执行这两种方法。例如,对于级联删除,它可以生成带有外键约束的代码ON DELETE CASCADE。对于应用层处理,它可以生成代码,在允许删除之前查询相关记录。关键在于明确说明你的数据完整性要求,而不是假设人工智能会根据你的特定领域推断出合适的行为。
The AI can implement either approach effectively when given clear direction. For cascade deletes, it might generate foreign key constraints with ON DELETE CASCADE. For application-level handling, it could produce code that queries for related records before permitting deletion. The key lies in explicitly stating your data-integrity requirements rather than assuming the AI will infer the appropriate behavior for your specific domain.
现在,您已经借助 AI 构建了前端和后端,接下来的挑战是将它们集成到一个无缝的 Web 应用程序中。这包括确保前端正确调用 API 端点,数据流正常,以及整个系统保持一致性。
Now that you’ve built both your frontend and backend with AI help, the next challenge is integrating them into a seamless web application. This involves making sure that the API endpoints are called correctly from the frontend, the data flows properly, and the overall system is coherent.
这一点至关重要:前端期望接收特定格式的数据,因此后端发送的数据应该符合这种期望。如果让 AI 分别独立处理前端和后端,可能会出现一些小的不匹配(例如,后端可能返回一个值{ success: true, data: [...] },但前端期望直接接收数组)。为了避免这种情况,可以在编写后端和前端代码时,明确指示 AI 使用哪种响应格式。或者,在后端和前端都完成后,测试一下端到端调用:例如,打开 Web 应用,查看列表是否加载。如果列表没有加载,请检查浏览器控制台和服务器日志。
This is crucial: the frontend expects to receive data in a certain shape, so what the backend sends should match that expectation. If you let AI work on each end in isolation, small mismatches can occur (maybe the backend returns { success: true, data: [...] }, but the frontend expects to receive the array directly). To avoid this, you can explicitly instruct the AI on the response format to use when coding both sides. Alternately, once both are done, test an end-to-end call: for instance, open the web app and see if the list loads. If it doesn’t, check the browser console against the server logs.
我经常使用人工智能来调整一侧,使其与另一侧相匹配:
I often use the AI to adjust one side to match the other:
如果后端返回的 JSON 键名与前端预期略有不同,并且您发现存在错误,您可以对 AI(无论在后端还是前端)说:
修改代码,在 JSON 中使用“tasks”(复数)代替“taskList”(单数)。
If the backend returns slightly different JSON key names than what the frontend expects and you notice a bug, you can say to the AI (on either side):
Modify the code to use ‘tasks’ (plural) instead of ‘taskList’ (singular) in the JSON.
如果前端以表单编码的形式发送表单数据,但后端需要 JSON 格式,您可以让 AI 进行转换,或许可以通过JSON.stringify在前端使用或body-parser在后端添加来实现。
If the frontend is sending form data as form-encoded but the backend expects JSON, you can ask the AI to convert that, maybe by using JSON.stringify on the frontend or adding body-parser on the backend.
像 Cline 或 Cursor 这样能够保留整个项目上下文的 AI 增强型 IDE,在这个集成阶段会特别有帮助。您可以在基于 IDE 的工具中并排打开前端和后端文件,然后提示:
AI-augmented IDEs that hold the context of the whole project, like Cline or Cursor, can be especially helpful during this integration phase. You could open the frontend and backend files side by side in your IDE-based tool and prompt:
确保前端从 /api/to-dos 获取的数据与 Express 路由预期的请求/响应相匹配。修复任何差异。
Ensure that the frontend fetch from /api/to-dos matches the Express route’s expected request/response. Fix any discrepancies.
然后,人工智能可能会协调内容(例如,如果前端缺少 await response.json(),则添加它,或者调整 JSON 结构)。
The AI might then harmonize the content (like adding await response.json() in the frontend if it was missing or adjusting the JSON structure).
在全栈应用程序中,考虑实现诸如加载状态之类的东西并对前端失败的 API 调用进行错误处理,以获得专业的结果。您可以使用如下提示:
In a full stack app, consider implementing things like loading states and error handling on the frontend for failed API calls for a professional result. You might use prompts like:
添加加载指示器:当 React 组件获取任务时,显示“正在加载...”文本,直到数据加载完成。
Add loading indicators: when the React component is fetching tasks, show a ‘Loading...’ text until data is loaded.
或者:
Or:
处理错误:如果 API 调用失败(非 200 响应),则在 UI 上显示错误消息。
Handle errors: if the API call fails (non-200 response), show an error message on the UI.
它会添加isLoading状态和条件渲染,或者实现 try/catch 语句fetch来捕获错误并显示错误信息。这种优化能让你的应用感觉更健壮。
It will add the isLoading state and conditional rendering or implement a try/catch around fetch to catch errors and display a message. This kind of polish makes your app feel robust.
如果你的如果应用程序需要实时更新(例如使用 WebSocket 或 SSE),您可能会收到类似这样的提示:
If your app requires real-time updates (like using WebSockets or SSE), you might prompt something like this:
使用 Socket.io 设置 WebSocket 连接。当服务器上创建新任务时,将其广播给所有已连接的客户端。修改前端,使其监听新任务并实时将其添加到列表中。
Set up a WebSocket using Socket.io. When a new task is created on the server, broadcast it to all connected clients. Modify the frontend to listen for new tasks and add them to the list in real time.
这很复杂,但人工智能可以生成服务器端的 Socket.io 配置(例如,io.on('connection', ...)在创建新任务时添加并发出事件),以及用于连接和监听该事件的客户端代码。你需要仔细地集成这些组件,但令人惊讶的是,这些描述竟然可以转化为可实时运行的代码。如果一开始无法完美运行,可以通过反复提示和测试来逐步完善。
This is complex, but an AI might generate the server-side Socket.io setup (like adding io.on('connection', ...) and emitting an event upon creation of a new task), as well as client-side code to connect and listen for that event. You would need to integrate this carefully, but it’s quite astonishing that these descriptions can lead to working real-time code. If it doesn’t work perfectly off the bat, iterative prompting and testing can get it there.
举例来说,假设你构建一个简单的联系人管理 Web 应用程序:
To illustrate, let’s imagine you’re building a simple contact-manager web app:
你需要搭建一个 React 前端和一个 Node/Express 后端,就像你在本章前面所做的那样。
You scaffold a React frontend and a Node/Express backend, as you did earlier in the chapter.
首先,对于前端,提示输入 aContactList和 aContactForm组件。然后提示添加 API 调用:
在 ContactList 中,挂载时从/api/contacts获取联系人。
在 ContactForm 中,提交时,
POST向/api/contacts发送包含表单数据的请求,然后在成功后更新联系人列表。
First, for the frontend, prompt for a ContactList and a ContactForm component. Then prompt to add API calls:
In ContactList, fetch contacts from /api/contacts on mount.
In ContactForm, on submit, send a
POSTto /api/contacts with the form data, then update the list of contacts on success.
对于后端,您可能需要先使用内存数组或集成数据库。然后提示用户选择 Express 路由GET /api/contacts(返回列表)和POST /api/contacts(将联系人添加到数据库或内存)。
For the backend, you may want to use an in-memory array or integrate a database first. Then prompt for Express routes GET /api/contacts (to return a list) and POST /api/contacts (to add a contact to the database or memory).
尝试通过用户界面添加联系人。如果联系人出现在列表中,那就太好了。如果没有出现,请进行调试。可能是路由POST没有正确返回新联系人,或者表单代码没有刷新列表。找出问题所在,并提示 AI 进行修复:
添加联系人后,后端应在响应中返回新的联系人对象,前端应将其添加到列表中,而无需完全重新加载。
这可能会导致 AI 调整后端响应和前端状态逻辑来推送新联系人(可能使用 React 状态更新)。
Try adding a contact via the UI. If it shows up in the list, great. If not, debug. Maybe the POST route didn’t return the new contact properly or the form code didn’t refresh the list. Identify the gap and prompt the AI to fix it:
After adding a contact, the backend should return the new contact object in the response, and the frontend should append it to the list without requiring a full reload.
This might lead the AI to adjust the backend response and frontend state logic to push the new contact (maybe using React state update).
编辑和删除功能的实现方式类似,每次都让 AI 处理例行部分,而将你的输入集中在该功能应该做什么上。
Implement edit and delete functions similarly, each time letting AI handle the routine parts and focusing your input on what the feature should do.
如果手动完成所有这些工作,对于初级开发人员来说可能需要一到两周的时间,但如果与人工智能合作开发人员一起工作,由于很多模板代码和连接都是自动化的,那么一两天内就可以完成。
Doing all this manually could easily amount to a week or two of work for a junior dev but could be done in a day or two with an AI codeveloper, given that a lot of template code and wiring is automated.
在处理整个技术栈时,与 AI 助手建立高效的工作节奏非常重要。以下是一些优化协作的策略:
When working through an entire stack, it’s useful to establish a productive rhythm with your AI assistant. Here are some strategies to optimize your collaboration:
识别代码中哪些部分是重复性的,哪些部分是独特的核心逻辑。让 AI 生成 CRUD API 或标准组件——但如果遇到特别复杂的逻辑,例如专有算法或更易于直接实现的特定业务规则,则手动完成这部分,然后再让 AI 进行审查或测试。可以将其理解为将重复性任务委托给 AI,而你则负责处理新颖的任务。
Identify which parts of the code are mundane and which are the unique core logic. Let the AI generate a CRUD API or a standard component—but if there’s a particularly tricky piece of logic, maybe a proprietary algorithm or a specific business rule that is easier to implement directly, do that part manually, then ask the AI to review or test it. Think of it as delegating repetitive tasks to the AI, while you handle the novel ones.
在开发过程中,请记录各项任务(例如要添加的功能和要修复的错误)。然后,逐一向 AI 解释每项任务,让它提出解决方案。例如,假设你有一条备注:“在用户注册时实现密码哈希”。可以尝试这样提示:
As you develop, keep track of tasks (like features to add and bugs to fix). Then explain each task to the AI, one by one, and let it propose a solution. For example, let’s say you have a note that reads “Implement password hashing on user registration.” Try a prompt like this:
POST /api/register在路由中保存用户之前,使用 bcrypt 添加密码哈希功能。
Add password hashing using bcrypt in the
POST /api/registerroute before saving the user.
这种有针对性、系统化的方法有助于确保您不会遗漏任何事情。
This targeted, systematic approach helps ensure you don’t forget anything.
实现功能后,您可能会提示“重构这段代码以提高可读性”或“优化这个函数”。人工智能通常可以简化代码或提出性能改进建议,就像助手在您的指导下进行二次润色一样。请务必验证所有更改是否仍然能够通过测试。
After achieving functionality, you might prompt, “Refactor this code for better readability” or “Optimize this function.” The AI can often make the code cleaner or suggest performance improvements, like an assistant doing a second pass for polish under your supervision. Be sure to verify that any changes still pass your tests.
如果你对自己的设计方案没有把握,可以咨询人工智能:
If you’re uncertain about your design approach, ask the AI:
使用数组在内存中存储联系人信息是否可行,还是应该使用数据库?两者的优缺点是什么?
Is using an array to store contacts in memory fine or should I use a database? What are the pros and cons?
虽然你可能已经知道答案(使用数据库进行数据持久化),但这就像和同事交流想法一样。有时,人工智能可能会提出一些你没有想到的考虑因素:
While you likely know the answer (use a database for persistence), it’s like bouncing ideas off a colleague. Sometimes the AI might mention a consideration you hadn’t thought of:
如果存在多个服务器实例,内存存储将无法在它们之间同步。
If there are multiple server instances, an in-memory store won’t sync across them.
如果你在团队中工作,可能并非每个人都直接使用人工智能。在这种情况下,务必让人工智能记录你的操作。此外,最好与团队沟通你的方法:“我使用人工智能快速生成了这些控制器。我已经检查过了,但请大家留意任何异常模式。” 鼓励建立代码审查文化,让每个人都像审查其他代码一样审查人工智能编写的代码,以便发现任何异常情况。
If you’re working in a team, not everyone may be using the AI directly. In that case, make sure to ask the AI to document what you did. Also, it’s good to communicate your approach to the team: “I used an AI to generate these controllers quickly. I’ve checked them, but keep an eye out for any unconventional patterns.” Encourage a code-review culture in which everyone reviews AI-written code just like they would any other code to catch any quirks.
实际应用中采用人工智能的团队(例如Snyk的团队)表示,人工智能可以提高生产力,但他们也强调需要人工参与验证。GitHub 在2024 年的一项调查显示,97% 的开发者表示他们在工作中以某种方式使用过人工智能编码工具。
Real-world teams that adopt AI (like those at Snyk) report that it can boost productivity, but they also stress keeping a human in the loop for validation. In one 2024 survey by GitHub, 97% of developers reported using AI coding tools at work in some capacity.
借助人工智能构建 Web 应用程序后,请进行测试彻底确保确保一切按预期运行,并能发现您或人工智能可能引入的问题。以下是在人工智能辅助环境下进行测试的方法:
After building your web app with AI help, test thoroughly to ensure everything works as intended and to catch issues that you or the AI might have introduced. Here’s how you can approach testing in this AI-assisted context:
对于后端逻辑,请为关键功能(例如计算某些内容或验证输入的函数)编写单元测试。如果函数是由人工智能编写的,那么为其编写测试可以发现任何隐藏的错误。如前所述,你甚至可以让人工智能生成这些测试。不过要小心:人工智能生成的测试有时过于简单或基于某种实现方式,因此你可能需要引导它测试一些边界情况。
For backend logic, write unit tests for critical functions (like a function that calculates something or validates input). If the AI wrote the function, writing a test for it can reveal any hidden bugs. You can even have the AI generate these tests, as mentioned. Be cautious, though: AI-generated tests are sometimes trivial or assume an implementation, so you may need to guide it to test edge cases:
编写密码强度函数的测试,包括空密码、超长密码、包含特殊字符的密码等极端情况。
Write tests for the password strength function, including edge cases like empty password, very long password, password with special chars, etc.
使用以下命令测试 API 端点可以使用类似 Supertest(适用于 Node)的工具或直接调用 HTTP 服务。检查每个端点是否返回预期结果。人工智能可以帮助您搭建这些框架:
Test the API endpoints with something like Supertest (for Node) or direct HTTP calls. Check that each endpoint returns the expected results. AI can help you scaffold these:
使用 Jest 和 Supertest 为 /api/to-dos 端点编写集成测试。
Write integration tests for the /api/to-dos endpoints using Jest and Supertest.
它可以生成启动应用程序、访问端点并断言响应的测试。
It might produce tests that start the app, hit the endpoints, and assert on responses.
可以进行 Web UI 测试可以使用 Jest(用于组件逻辑)和 Cypress 或 Playwright 等工具进行端到端 UI 测试。当然,您也可以让 AI 生成 Cypress 测试场景:
Web UI testing can be done with tools like Jest (for component logic) and Cypress or Playwright for end-to-end UI tests. You can certainly ask AI to generate a Cypress test scenario:
编写一个 Cypress 测试,加载应用程序,通过表单添加新的待办事项,并检查它是否出现在列表中。
Write a Cypress test that loads the app, adds a new to-do via the form, and checks that it appears in the list.
你会得到一个测试脚本,你可以运行它。这非常强大——通过利用人工智能编写用户交互脚本,你可以快速获得端到端的测试覆盖率。
You’ll get a test script, which you can run. This is quite powerful—you quickly get end-to-end test coverage by leveraging the AI to script user interactions.
无论运行什么自动化测试,都务必进行一些手动探索性测试。亲自浏览 Web 应用(如果是团队合作,可以请 QA 团队来完成)。人工智能可能无法预料到所有实际场景:例如,使用浏览器后退按钮可能会破坏某些状态,或者特定的操作序列会导致故障。发现 bug 后,请自行修复,或者请求人工智能协助修复。手动测试对于 UI/UX 评估也至关重要——应用的使用体验如何?是否存在任何不流畅的操作流程?人工智能无法判断这些主观的 UX 问题,因此人工反馈至关重要。
Whatever automated tests you run, always do some manual exploratory testing, too. Click around the web app yourself (or have QA do it, if you’re working in a team). The AI might not anticipate every real-world scenario: for example, maybe using the browser Back button breaks some state, or a particular sequence of actions causes a glitch. As you find bugs, fix them or ask the AI to help fix them. Manual testing is also important for UI/UX judgment—does the app feel good to use? Are there any awkward flows? The AI won’t know how to judge these subjective UX issues, so human feedback is key.
如果你与他人合作,请准备好让他们审查人工智能生成的代码。新的视角可以发现你可能忽略的问题——他们可能会发现安全漏洞,或者仅仅是建议一种更符合惯用语的写法。使用人工智能的团队通常会保留常规的代码审查流程,只是更加注重审查人工智能可能无意中引入的细微错误或安全问题。
If you’re working with others, have them review the AI-generated code. Fresh eyes can catch things you might have glossed over—they might spot a security oversight or simply suggest a more idiomatic way to write something. Teams using AI often maintain normal code-review processes, just with more focus on reviewing for subtle bugs or security issues that an AI might inadvertently introduce.
第 8 章将深入探讨安全性,但即使在开发阶段,扫描代码以查找已知的漏洞模式也是值得的。您可以使用一些自动化工具,例如代码检查工具和静态应用程序安全测试(SAST) 工具,或者您可以引导 AI 进行操作:
Chapter 8 will dive into security, but even at development time, it’s worth scanning your code for known vulnerability patterns. There are automated tools you can run, like linters and Static Application Security Testing (SAST) tools, or you can prompt the AI:
检查 Express 应用代码,并列出任何潜在的安全漏洞或违反最佳实践的情况。
Review the Express app code and list any potential security vulnerabilities or best practice violations.
人工智能可能会标记出一些令人惊讶的问题,例如“您没有对用户输入进行清理”或“您应该正确设置 CORS”。您可以将此作为强化应用程序安全性的检查清单。
The AI might flag some surprising things, like “You are not sanitizing user input here” or “You should set up CORS properly.” Use that as a checklist for hardening the app.
使用人工智能的一个有趣之处在于,你可能会编写一些原本不会编写的测试,因为人工智能让创建测试变得如此简单。这最终实际上可以带来更健壮的代码。如果你养成在生成功能后立即生成测试的习惯(本质上是人工智能辅助的测试驱动开发,或者至少是事后测试),就能确保快速开发不会影响质量。不妨这样想:既然人工智能帮你节省了编写代码的时间,那就把节省下来的时间投入到编写和运行测试中吧。
One interesting effect of using AI is that you may write tests you wouldn’t have otherwise, because the AI makes it so easy to create them. This can actually lead to more robust code in the end. If you adopt a practice of generating tests immediately after generating features (essentially AI-assisted test-driven development, or at least post hoc tests), you ensure that the rapid development doesn’t compromise quality. Think of it like this: since the AI saved you time writing code, invest some of that saved time into writing and running tests.
如果用户不谨慎,人工智能可能会建议编写不安全的代码。例如,早期版本的人工智能可能会生成容易受到注入攻击的 SQL 查询,除非用户明确提示避免这种情况。通过测试和审查,可以发现这些问题。一项研究发现,使用人工智能辅助的开发人员往往对其代码的安全性过于自信,即使这些代码的安全性比手动编写的代码更差。
AI can suggest insecure code if the user isn’t careful. For example, earlier AI versions might generate SQL queries that are vulnerable to injection attacks if not specifically prompted to avoid that. By testing and reviewing, you catch these issues. One study found that developers using AI assistance tended to be overconfident in their code’s security, even when it was worse than it would’ve been if written manually.
切勿因为代码是人工智能编写的就忽略验证环节。要假设它和任何人类编写的代码一样,都可能存在漏洞。
Never skip validation just because an AI wrote the code. Assume it can have bugs, just like any human-written code.
让我们重点介绍几个例子(综合了各种报告),在这些例子中,人工智能辅助在交付真正的网络应用程序方面发挥了重要作用。
Let’s highlight a couple of examples (composites drawn from various reports) where AI assistance played a significant role in delivering real web applications.
一位独立开发者想要创建一个小型电子商务网站应用程序来销售定制T恤,但他时间有限。他利用 IDE 扩展程序,通过 GPT 构建了整个技术栈。他引导 AI 生成了一个包含产品列表、购物车和结账页面的 React 前端,以及一个包含产品和订单接口的 Node.js 后端。他使用 Stripe 进行支付,并通过让 AI 协助调用 Stripe 的 API 来实现集成。经过两周的夜间开发,他终于拥有了一个可以正常运行的网站。
A solo developer wanted to create a small ecommerce web app to sell custom T-shirts but had limited time. He used GPT, through an IDE extension, to build the entire stack. He prompted the AI to generate a React frontend with product listings, a cart, and checkout pages, as well as a Node.js backend with endpoints for products and orders. He used Stripe for payments, integrating it by asking the AI to help with Stripe’s API. After working on it in the evenings for two weeks, he had a functioning site.
这位开发者表示,人工智能完成了大约 70% 的代码编写工作,特别是重复的 UI 部分和表单处理,而他则专注于正确配置 Stripe 并针对品牌进行 UI 微调。最终,客户可以浏览产品、将其添加到购物车并完成购买——所有这些操作都可以在一个主要采用 Vibe 编码构建的系统中完成。这也表明,只要有可供模型参考的文档(或者由开发者提供),在人工智能的指导下集成外部服务(例如 Stripe)是可行的。
This developer reported that AI had done probably 70% of the coding, especially the repetitive UI parts and form handling, while he focused on configuring Stripe correctly and fine-tuning the UI for branding. In the end, customers could browse products, add them to the cart, and purchase them—all in a system built largely via vibe coding. It also highlights that external service integration (like Stripe) is feasible with AI guidance, as long as documentation is available for the model to draw from or you provide it.
一位具备一定编程技能的产品经理利用人工智能结对编程技术,为她的团队创建了一个内部分析仪表板。通常情况下,她需要等待工程资源,但借助 Replit 的 Ghostwriter 或 GitHub Copilot 等工具,她成功地在 Web 项目中自行构建了一个基本的 Web 应用。人工智能帮助她搭建了一个简单的 Flask 后端来查询数据库(使用安全的只读凭据),以及一个 Vue.js 前端来显示图表(使用图表库)。她描述了每个图表应该显示的内容(例如“一段时间内的总注册用户数”、“按地区划分的活跃用户数”),人工智能则编写了 SQL 查询和图表代码。
A product manager with some coding skills used an AI pair programmer to create an internal analytics dashboard for her team. Normally, she would have had to wait for engineering resources, but using a tool like Replit’s Ghostwriter or GitHub Copilot in a web project, she managed to build a basic web app herself. The AI helped with setting up a simple Flask backend to query their database (with safe read-only credentials) and a Vue.js frontend to display graphs (using a charting library). She described what each chart should show (“total sign-ups over time,” “active users by region”), and the AI wrote the SQL queries and chart code.
整个过程耗时两周左右,期间她不断调整和测试,最终交付了一个可用的仪表盘。代码质量虽然达不到企业级水平,但由于是内部项目,所以也无妨。更重要的是,她用极短的时间就为团队提供了一个强大的工具。这个例子说明了人工智能工具如何帮助非专业程序员开发出实用的Web应用程序,从而解决那些原本可能积压的任务。这正是我将在第十章讨论的“程序员角色解绑”的一个例子,第十章将着重探讨个人如何更轻松地创建个人或团队专属软件。
The whole process took a couple of weeks of tinkering and testing, but eventually she delivered a working dashboard. The code quality wasn’t enterprise grade, but since it was internal, it was fine. More importantly, she empowered her team with a tool in a fraction of the time. This example illustrates how AI tools can enable nonspecialist programmers to produce useful web apps, unblocking tasks that might otherwise sit in a backlog. It’s an example of the “unbundling of the programmer” that I’ll discuss in Chapter 10, which is all about how individuals can create personal or team-specific software more easily now.
一家小型创业公司(只有两位联合创始人:一位负责业务,一位负责技术)需要一个 MVP 网络应用程序来向投资者展示。技术联合创始人大量运用了 Vibe 编码,在创纪录的时间内构建了一个 MVP(最小可行产品)。他利用人工智能助手,以 Next.js 构建了基于 React 的服务器端渲染前端,并使用了一个简单的 Node API,搭建了一个现代化的 Web 应用。他运用人工智能实现了社交登录(人工智能编写了 OAuth 流程)、图片上传(人工智能集成了云存储 API)以及产品内置的人工智能功能。他们甚至还利用人工智能集成了一个来自 API 的自然语言处理模型。短短几个月,一位开发者就完成了通常一个小团队需要四到六个月才能完成的工作。最终成果是一个功能齐全但略显粗糙的产品,他们可以进行演示,甚至可以邀请测试用户加入平台。
A small startup (just two cofounders: one business, one technical) needed an MVP web application to show to investors. The technical cofounder used vibe coding extensively to build an MVP in record time. Using an AI assistant, he scaffolded a modern web app using Next.js for the SSR React frontend and a simple Node API. He leveraged AI to implement features like social login (the AI wrote the OAuth flows), image uploads (the AI integrated with a cloud-storage API), and an AI-based feature within the product itself. They even used the AI to help integrate an NLP model from an API. In a few months, one developer achieved what might normally take a small team four to six months. The result was a somewhat hacky but functioning product that they could demo, and they could even onboard beta users onto the platform.
后来,联合创始人聘请了更多开发人员来完善产品。新来的开发人员发现,人工智能编写的代码大部分都易于理解,尽管他们为了提高可扩展性,还是重构了相当一部分代码。这表明,人工智能可以帮助你快速达到第一阶段,但随着你进入后续阶段,你可能需要加大对质量的投入。
When the cofounders later hired more devs to polish the product, the new devs found the AI-written code to be mostly understandable, though they did refactor significant portions for scalability. This underlines that AI can get you to the first stage quickly, but you might need to invest in quality as you move to the next stages.
这些案例虽然只是个例,却与行业内正在涌现的新趋势相符。尤其是在Web开发领域,由于经常需要将众多组件连接起来,生产力的提升非常显著。微软和其他公司发布的研究报告显示,使用人工智能的开发人员完成任务的速度明显快于未使用人工智能的开发人员。
These stories, while anecdotal, align with emerging patterns in the industry. In web development specifically, which often involves wiring many components together, the productivity boost is very tangible. Microsoft and others reported studies finding that developers with AI could complete tasks significantly faster than those without.
然而,也有一些值得警惕的案例。例如,开发人员可能因为对代码理解不够透彻,而部署了一个存在安全漏洞的AI生成的Web应用程序。这种风险凸显了测试和审查的重要性。
However, there have also been cautionary tales. For instance, a developer might deploy an AI-generated web app with a security flaw because they don’t fully understand the code. This risk reinforces why testing and review are crucial.
总之,借助人工智能辅助构建Web应用程序正逐渐成为主流方法。这并非取代熟练的开发人员,而是增强他们的工作能力。开发人员仍然负责规划架构、确保代码的正确性以及处理代码中复杂或新颖的部分,而人工智能则负责编写将所有功能连接起来的重复性样板代码。我们演示的端到端工作流程——从框架搭建到前端、后端再到测试——表明,只要在开发过程中始终运用人类的判断力和专业知识,人工智能几乎可以加速Web开发的每个步骤。
In conclusion, building web applications with AI assistance is becoming a mainstream approach. It doesn’t remove the need for skilled developers; rather, it augments them. The developers still plan the architecture, ensure correctness, and handle the complex or novel aspects of the code, while the AI handles the repetitive boilerplate code that glues everything together. The end-to-end workflow we walked through—from scaffolding to frontend to backend to testing—demonstrates that practically every step of web development can be accelerated with AI, as long as you apply your human judgment and expertise along the way.
在本章中,您已经了解了如何将Vibe编码扩展到完整的Web应用程序开发。通过将AI视为随时可用的结对程序员,您可以并行处理前端和后端任务,根据自然描述生成组件和API,并迭代地将原型应用程序完善到生产级别。成功的关键包括:清晰地传达您的意图(以便AI了解您在每个步骤中的需求)、仔细验证(以发现AI输出中的问题),以及利用AI不仅生成代码,还用于诸如集思广益地设计架构和编写测试等工作。
In this chapter, you’ve seen how vibe coding extends to full-scale web application development. By treating the AI as an always available pair programmer, you can tackle frontend and backend tasks in parallel, generate components and APIs from natural descriptions, and iteratively refine a prototype application to production quality. The keys to success include clearly communicating your intent (so the AI knows what you want at each step), carefully verifying (to catch issues in the AI output), and leveraging the AI not just to generate code but for things like brainstorming schema designs and writing tests.
本章还探讨了开发者如何才能有效地成为全栈工程师,借助人工智能弥补知识上的不足,在他们不太熟悉的领域提供代码建议。这大大缩短了常用功能的开发时间,并在某些方面实现了开发民主化,使人们能够在无需大型团队的情况下创建定制化的Web解决方案(我将在第十章中再次探讨这一主题)。
This chapter also explored how a developer can effectively be a full stack engineer, augmented by AI bridging gaps in their knowledge by suggesting code in areas they are less familiar with. This greatly reduces development time for common features and democratizes development in some ways, enabling people to create custom web solutions without large teams (a theme I’ll revisit in Chapter 10).
人工智能并不能取代对需求的理解或对质量的保证;它只是加快了执行速度。
AI doesn’t replace understanding the requirements or ensuring quality; it accelerates execution.
现在您的 Web 应用程序已经上线运行,接下来要关注的是确保其安全性、可靠性和可维护性。第 8 章深入探讨了 AI 生成的代码库在安全性和可靠性方面面临的挑战,识别可能出现的常见漏洞,讲解如何进行审计和修复,以及最佳实践(例如我们在此处开始应用的测试和审查),以确保快速应用 AI 不会造成系统崩溃。本质上,我们将从构建转向加固——确保您的 vibe 代码能够经受住真实世界的考验和威胁。
Now that your web application is up and running, the next concern is making sure it is secure, reliable, and maintainable. Chapter 8 dives into the challenges of security and reliability in AI-generated codebases, identifying common vulnerabilities that might slip in, how to audit for and fix them, and best practices (like the ones we’ve started applying here with tests and reviews) to ensure that moving fast with AI doesn’t break things. Essentially, we’ll shift from building to hardening—making sure your vibe-coded software stands up to real-world conditions and threats.
本章探讨了振动编码和人工智能辅助工程的一个关键方面——确保使用人工智能辅助生成的代码是安全、可靠和可维护的。如果最终的软件漏洞百出或容易崩溃,那么速度和生产力就毫无意义。
This chapter confronts a critical aspect of vibe coding and AI-assisted engineering—ensuring that the code you produce with AI assistance is secure, reliable, and maintainable. Speed and productivity mean little if the resulting software is riddled with vulnerabilities or prone to crashing.
首先,我将探讨人工智能生成代码中常见的安全陷阱,从注入漏洞到密钥泄露。你将学习如何审计和审查人工智能编写的代码,以发现此类问题,从而有效地为你的人工智能结对程序员提供安全保障。
First, I’ll examine common security pitfalls that arise in AI-generated code, from injection vulnerabilities to secrets leakage. You’ll learn techniques for auditing and reviewing AI-written code for such issues, effectively acting as the security safety net for your AI pair programmer.
接下来,我将探讨如何围绕人工智能生成的代码构建有效的测试和质量保证框架,以便及早发现错误和可靠性问题。性能方面的考量也将涵盖在内。人工智能或许能够编写正确的代码,但并非总是最高效的代码,因此我将概述如何识别和优化性能瓶颈。此外,我还会探讨确保代码可维护性的策略,例如强制执行一致的代码风格或重构人工智能代码,因为人工智能的建议有时可能不一致或过于冗长。
Next, I’ll discuss building effective testing and QA frameworks around AI-generated code to catch bugs and reliability issues early. Performance considerations will also be covered. AI might write correct code, but it’s not always the most efficient code, so I’ll outline how to identify and optimize performance bottlenecks. I’ll also explore strategies to ensure maintainability, such as enforcing consistent styles or refactoring AI code, since AI suggestions can sometimes be inconsistent or overly verbose.
我将向您展示如何调整代码审查流程以适应人工智能辅助的工作流程,重点阐述人类审查员在审查部分或全部由机器生成的代码时应关注哪些方面。最后,我将总结部署人工智能辅助项目的最佳实践,涵盖从持续集成流水线到生产环境监控等各个方面,帮助您更有信心地完成项目。在本章结束时,您将掌握一系列方法,确保您的人工智能加速开发过程安全可靠。
I’ll show you how to adapt your code-review practices to an AI-assisted workflow, highlighting what human reviewers should focus on when reviewing code that was partially or wholly machine-generated. Finally, I’ll round up best practices for deploying AI-assisted projects with confidence, from continuous integration pipelines to monitoring in production. By the end of this chapter, you’ll have a toolkit of approaches to keep your AI-accelerated development safe and robust.
AI编码助手虽然功能强大,但如果使用不当,可能会无意中引入安全问题。它们会从大量的公开代码中学习——这些代码既包含好的实践,也包含坏的实践——如果提示或上下文没有引导它们避开这些不安全模式,它们可能会照搬这些模式。了解这些常见的陷阱至关重要,这样你才能发现并修复它们。这包括使用手动和自动化方法来检测潜在的安全问题(参见图 8-1)。
AI coding assistants, while powerful, can inadvertently introduce security issues if not guided properly. They learn from lots of public code—which includes both good and bad practices—and may regurgitate insecure patterns if the prompt or context doesn’t steer them away. It’s vital for you to know these common pitfalls so you can spot and fix them. This can include using both manual and automated means to detect potential security issues (see Figure 8-1).
人工智能生成的代码中常见的一些安全问题包括:
Some typical security issues observed in AI-generated code include:
有时人工智能输出代码中不应包含 API 密钥、密码或令牌,尤其是在其训练数据中包含类似示例的情况下。例如,如果您要求它与 AWS 集成,它可能会直接在代码中放入一个虚拟的 AWS 密钥。如果保留这些密钥,将会非常危险——一旦代码被共享,就可能泄露敏感信息。务必确保通过环境变量或配置文件妥善管理密钥。如果 AI 建议使用类似 ` <key>` 这样的api_key = "ABC123SECRET"密钥,请将其视为警告——真正的密钥不应该出现在源代码中。
Sometimes AI outputs API keys, passwords, or tokens in code, especially if similar examples were in its training data. For instance, if you ask it to integrate with AWS, it might put a dummy AWS secret key directly in the code. This is dangerous if left in—it could leak sensitive info if the code is shared. Always ensure that secrets are properly managed via environment variables or config files. If an AI suggests something like api_key = "ABC123SECRET", treat it as a flag—real keys should not be in source code.
如果你有你的AI 模型生成 SQL 查询或 ORM 使用情况时,请检查它是否直接通过拼接用户输入来构建查询。例如,一种不安全的模式是:
sql = "SELECT * FROM users WHERE name = '" + username + "'";
这容易受到注入攻击。如果您没有明确指示 AI 对查询进行参数化,它可能会生成此类错误。请始终使用预处理语句或参数绑定。许多 AI 助手如果记住最佳实践(例如?在 SQL 中使用占位符来表示用户输入),就会这样做,但这并不能保证。您有责任进行验证,并在必要时要求 AI 进行修复。
修改此查询语句,使其使用参数以防止 SQL 注入。
If you have your AI model generate SQL queries or ORM usage, check that it’s not constructing queries by concatenating user input directly. For example, an insecure pattern would be:
sql = "SELECT * FROM users WHERE name = '" + username + "'";
This is susceptible to injection attacks. An AI might produce this if you don’t specifically tell it to parameterize queries. Always use prepared statements or parameter binding. Many AI assistants will do so if they recall best practices (like using ? or placeholders for user inputs in SQL), but it’s not guaranteed. It’s on you to verify and ask the AI to fix it if needed:
Modify this query to use parameters to prevent SQL injection.
在生成网页代码时,AI 工具并不总是会自动转义输出中的用户输入。例如,您的 AI 可能会生成一个模板代码片段,该代码片段会直接插入{{comment.text}}到 HTML 中而不进行转义,这可能导致注释中放置的恶意脚本运行。如果使用框架,AI 通常默认会进行转义,但如果它们处理原始 HTML 代码,则需要格外小心。请实现输出编码或清理程序。您可以提示 AI:
对用户输入进行清理以防止 XSS 攻击。
许多现代框架都有内置机制,因此要确保 AI 使用这些机制,例如在文档对象模型 (DOM) 操作中使用innerTextvs.innerHTML
When generating web code, AI tools don’t always automatically escape user input in outputs. For example, your AI might produce a templating snippet that directly inserts {{comment.text}} into HTML without escaping, which could allow a malicious script placed in a comment to run. If using frameworks, AIs often escape by default, but if they’re handling raw HTML construction, be careful. Implement output encoding or sanitization routines. You can prompt the AI:
Add sanitization for user inputs to prevent XSS.
Many modern frameworks have built-in mechanisms, so ensure that the AI uses them, like innerText versus innerHTML in Document Object Model (DOM) manipulation.
人工智能可以写作身份验证流程,但可能会出现一些不易察觉的错误:例如,生成JSON Web Token (JWT)时没有足够强大的密钥,或者没有正确检查密码哈希值。
授权也是如此:人工智能可能不会自动强制执行某个操作(例如删除资源)仅限该资源的所有者执行。这些逻辑问题很难自动发现,需要仔细考虑安全模型。编写此类代码时,务必明确规定:
确保只有资源所有者才能删除资源。添加用户 ID 检查。
然后测试这些条件。人工智能很容易漏掉某些检查,因为除非被告知,否则它无法真正“理解”上下文。
AIs can write authentication flows, but subtle mistakes might creep in: for instance, generating a JSON Web Token (JWT) without a sufficiently strong secret or not checking a password hash correctly.
The same is true for authorization: an AI might not automatically enforce that an action (like deleting a resource) is limited to the user who owns that resource. These logic issues are hard to catch automatically—they require thinking through the security model. When writing such code, specify clearly:
Ensure that only the owner of the resource can delete it. Add checks for user ID.
Then test those conditions. It’s easy for an AI to omit a check because it doesn’t truly “understand” the context unless told.
人工智能可能会选择方便除非另有指示,否则默认启用安全措施。例如:
如果未指定 TLS,则 API 调用使用 HTTP 而不是 HTTPS。
未验证 SSL 证书(互联网上的一些代码示例verify=false在请求中使用,人工智能可能会复制这些证书)
广泛启用 CORS,允许所有来源和方法的请求而不加限制(可能会使应用程序面临任何跨域请求)。
选择过时的加密技术(例如使用安全性较低的 MD5 或 SHA1 进行哈希运算,而不是使用安全性较高的 SHA-256/Bcrypt/Argon2 进行密码加密)
这些问题通常很隐蔽,因此定期审核配置文件和初始化代码非常重要。如果人工智能设置了类似这样的错误app.UseCors(allowAll),或者选择了过时的加密算法,您应该及时发现并纠正。
AI might choose convenience over security unless prompted to do otherwise. Examples include:
Using HTTP instead of HTTPS for API calls (if TLS is not specified)
Not validating SSL certificates (some code examples on the internet use verify=false in requests, which AI might copy)
Widely enabling CORS for all origins and methods without restriction (potentially opening the app to any cross-origin requests)
Choosing outdated cryptography (like MD5 or SHA1 for hashes, which are weak, instead of SHA-256/Bcrypt/Argon2 for passwords)
These issues are often subtle, which is one reason it’s good to audit your configuration files and initialization code. If the AI sets up something like app.UseCors(allowAll) or chooses an old cipher, you should spot that and correct it.
人工智能生成的 错误处理可能会打印或返回堆栈跟踪信息。例如,Node.js API 可能会捕获错误并执行某些操作res.send(err.toString()),这可能会泄露内部细节。请确保向用户发送的错误信息经过脱敏处理,并妥善处理日志。根据需要进行调整,以避免向攻击者提供诸如完整错误信息或文件路径之类的线索。
AI-generated error handling might print or return stack traces. For example, a Node.js API might catch an error and do res.send(err.toString()), which could leak internal details. Ensure that error messages to users are sanitized and logs are properly handled. Adjust as needed to avoid giving attackers clues like full error messages or file paths.
如果人工智能添加对于项目的依赖项(例如库),请确保它们是最新版本,并且来自信誉良好的来源。人工智能可能会选择一个在其训练数据中很流行的库,但该库可能已停止维护或存在已知漏洞。例如,如果它建议使用某个软件包的旧版本,您应该将其升级到最新的稳定版本。npm audit生成后运行或执行类似操作也是明智之举。或者,您可以询问人工智能:
这个图书馆还在维护吗?安全吗?
它可能无法完全确定,但可以告诉你是否存在已知的弃用情况。
If the AI adds dependencies (such as libraries) to your project, ensure that they’re up to date and from reputable sources. An AI might pick a library that was popular in its training data, but that is no longer maintained or has known vulnerabilities. For instance, if it suggests using an older version of a package, you should bump it to the latest stable. Running npm audit or equivalent after generation is wise too. Or ask the AI:
Is this library still maintained and secure?
It might not fully know, but it could tell you if there’s a known deprecation.
2023 年一项针对 GitHub Copilot 在真实项目中应用的大规模分析显示,高达 25% 至 33% 的生成代码(具体比例取决于编程语言)包含潜在的安全漏洞,包括命令注入、代码注入和跨站脚本攻击等高危 CWE 。这些发现强调,Copilot 反映的是其训练数据中存在的不安全模式,而非故意生成有缺陷的代码。因此,我们始终建议开发者保持警惕:手动审查 AI 生成的代码,使用安全工具,并严格遵守代码规范。尤其是在“即兴编码”阶段,AI 生成代码的速度和范围要求我们更加谨慎。在更短的时间内生成更多代码意味着需要审核的范围更广。
A 2023 large-scale analysis of GitHub Copilot in real-world projects revealed that as much as 25%–33% of generated code—depending on language—contained potential security weaknesses, including high-severity CWEs such as command injection, code injection, and cross-site scripting. These findings underscore that Copilot reflects insecure patterns present in its training data, as opposed to intentionally producing flawed code. The consistent recommendation? Developers must stay alert: manually review AI-generated code, use security-aware tooling, and maintain strict code hygiene. Especially during “vibe coding,” the speed and scope of AI-generated content demand even more vigilance. More code in less time means more surface area to audit.
我们来看一个简单的例子。
Let’s look at a short example.
想象一下,你让人工智能创建一个登录账户。在 Express 应用中规划路线。它可能会产生类似这样的结果:
Imagine you ask an AI to create a login route in an Express app. It might produce something like this:
// Insecure exampleapp.post('/login',async(req,res)=>{const{username,password}=req.body;constuser=awaitUsers.findOne({username:username});if(!user)returnres.status(401).send("No such user");if(user.password===password){// plain text password comparisonres.send("Login successful!");}else{res.status(401).send("Incorrect password");}});
// Insecure exampleapp.post('/login',async(req,res)=>{const{username,password}=req.body;constuser=awaitUsers.findOne({username:username});if(!user)returnres.status(401).send("No such user");if(user.password===password){// plain text password comparisonres.send("Login successful!");}else{res.status(401).send("Incorrect password");}});
这里存在哪些问题?
What are the issues here?
它直接比较密码,这意味着密码以明文形式存储在数据库中——这是绝对不允许的。
It compares passwords directly, implying that the password is stored in plain text in the database—a big no-no.
它会发送非常通用的回复,这可能有利于安全,但也可能无意中泄露敏感信息。
It sends very generic responses, which may be appropriate for security but could also inadvertently expose sensitive information.
以身份验证错误消息为例进行分析。一个真正安全的系统在登录失败时,无论用户名还是密码错误,都应该返回类似“凭据无效”的通用消息。然而,人工智能生成的代码可能会产生更具体的错误信息,例如“找不到用户名”或“此用户的密码错误”。
Consider authentication error messages as a critical example. A properly secure system should return a generic message like “Invalid credentials” when login fails, regardless of whether the username or password was incorrect. However, AI-generated code might produce more specific errors such as “Username not found” or “Incorrect password for this user.”
这些特定信息营造了一种安全感。这种漏洞在于它向潜在攻击者确认了他们掌握的哪些信息是正确的。如果攻击者收到“密码错误”的错误提示,他们就知道自己已经找到了系统中一个有效的用户名。这使得他们可以通过反复尝试建立一个合法用户名列表,然后集中精力破解这些已确认账户的密码。这种被称为用户枚举的技术,将猜测游戏转化为更有针对性的攻击。人工智能倾向于提供有用的、具体的错误信息,除非你明确指示它对涉及安全敏感的操作保持适当的模糊响应,否则这种倾向会在无意中帮助恶意行为者。
These specific messages create a security vulnerability by confirming to potential attackers which piece of information they have correct. If an attacker receives “Incorrect password” as an error, they now know they have discovered a valid username in your system. This enables them to build a list of legitimate usernames through repeated attempts, then focus their efforts on cracking passwords for those confirmed accounts. This technique, known as user enumeration, transforms a guessing game into a more targeted attack. The AI’s tendency toward helpful, specific error messages inadvertently aids malicious actors unless you explicitly instruct it to maintain appropriately vague responses for security-sensitive operations.
虽然代码中没有显示,但没有速率限制。或者这里还包括其他保护措施。
While it isn’t shown in the code, no rate limiting or other protections are included here.
安全的实施方案应包含以下几项关键保障措施:
A secure implementation would incorporate several critical safeguards:
First and foremost, passwords should never be stored in plain text. Instead, the system should store cryptographically hashed passwords and use a secure comparison function to verify login attempts.
此比较过程必须采用恒定时间算法来防止计时攻击,攻击者通过分析响应时间来推断密码的正确性信息。许多专注于安全性的库都提供了这些恒定时间比较函数,专门用于解决此漏洞。
This comparison process must employ constant-time algorithms to prevent timing attacks, where attackers analyze response times to deduce information about password correctness. Many security-focused libraries provide these constant-time comparison functions specifically to address this vulnerability.
此外,身份验证系统应实施速率限制或节流机制,以防止暴力破解攻击。失败的登录尝试应被记录,以便进行安全监控,使管理员能够检测并应对可疑模式。这些措施共同构成纵深防御体系,即使某一安全层遭到破坏,也能保护用户凭据。
Additionally, the authentication system should implement rate limiting or throttling mechanisms to prevent brute-force attacks. Failed login attempts should be logged for security monitoring, allowing administrators to detect and respond to suspicious patterns. These measures work together to create a defense-in-depth approach that protects user credentials even if one security layer is compromised.
你可以借助人工智能来解决这个问题:
You can ask AI to help fix this:
改进登录路由,使用 bcrypt 对密码进行哈希处理和比较,并确保数据库中的密码已进行哈希处理。
Improve the login route to use bcrypt to hash and compare passwords, and ensure the password in the database is hashed.
然后它可能会输出:
It might then output:
constbcrypt=require('bcrypt');app.post('/login',async(req,res)=>{const{username,password}=req.body;constuser=awaitUsers.findOne({username});if(!user){returnres.status(401).send("Invalid credentials");}constmatch=awaitbcrypt.compare(password,user.passwordHash);if(!match){returnres.status(401).send("Invalid credentials");}res.send("Login successful!");});
constbcrypt=require('bcrypt');app.post('/login',async(req,res)=>{const{username,password}=req.body;constuser=awaitUsers.findOne({username});if(!user){returnres.status(401).send("Invalid credentials");}constmatch=awaitbcrypt.compare(password,user.passwordHash);if(!match){returnres.status(401).send("Invalid credentials");}res.send("Login successful!");});
这样更好:它会将密码bcrypt与哈希密码进行比较(假设变量user.passwordHash存储了哈希密码)。创建用户时,您还需要确保使用bcrypt.hash哈希算法来哈希用户的密码。
This is better: it uses bcrypt to compare against a hashed password (assuming the variable user.passwordHash stores that). When creating users, you’d also want to make sure to use bcrypt.hash to hash their passwords.
稍加引导,人工智能就能做出正确的判断,但它最初的简单输出很可能并不安全。这凸显了关键所在:审查和改进。
With a bit of guidance, the AI can do the right thing, but its initial naive output might well be insecure. This underscores the pattern: review and refine.
另一个常见的漏洞类别是软件包管理。人工智能有时会发明一个图书馆或者记错名称,这种情况被称为“包幻觉”。这样的包可能并不存在,但理论上,攻击者可以发布一些名称容易让人产生误解的包,其中包含恶意代码。如果您在未确认包是否存在且是否正确的情况下安装它,可能会引入严重的风险。如果您不确定某个包是否存在,请尝试快速搜索或直接在 npm/PyPI 上查找。
Another common vulnerability category is package management. AI sometimes invents a library or misremembers a name, a problem known as package hallucination. Such a package might not exist, but an attacker could, theoretically, publish packages under commonly hallucinated names that contain malicious code. If you install such a package without confirming that it both exists and is the correct package, you could be introducing serious risk. If you’re not sure about a particular package, try a quick web search or check npm/PyPI directly.
此外,人工智能可能会无意中生成与训练数据中的授权代码片段完全相同的代码。这更多的是一个知识产权问题,而不是安全问题,但值得认真对待。 例如,GitHub Copilot 包含重复代码检测功能,可以标记生成的代码是否与公共代码库高度匹配,从而帮助开发者避免潜在的许可冲突。类似的工具正在涌现,旨在解决人工智能生成代码溯源这一特定挑战。第九章将更深入地探讨许可和知识产权方面的考量,并提供应对这些复杂问题的全面指导。
Additionally, the AI might inadvertently produce code that is identical to a licensed snippet from training data. This is more an intellectual property concern than a security issue, but it warrants careful attention. GitHub Copilot, for instance, includes a duplicate detection feature that can flag when generated code closely matches public repositories, helping developers avoid potential licensing conflicts. Similar tools are emerging to address this specific challenge of AI-generated code provenance. Chapter 9 will delve into licensing and intellectual property considerations in more detail, providing comprehensive guidance on navigating these complex issues.
总而言之,本书的核心信息依然是——没错,我知道我在书中反复强调这一点,以至于你可能闭着眼睛都能背下来——那就是人工智能的输出需要像审查初级开发人员的代码一样仔细审查。这种重复是刻意的,因为这一原则几乎是安全有效的人工智能辅助开发各个环节的基础。无论你是进行原型设计、构建后端,还是实现安全功能,这种思维模式都能在信任和验证之间取得恰当的平衡,使人工智能成为强大的盟友,而不是充满风险的捷径。它可以快速编写大量代码,但你需要将安全最佳实践融入其中,并仔细检查是否存在漏洞。小说家弗兰克·赫伯特在《沙丘之神》 (普特南出版社,1981年)中有一句广为流传的名言,他这样说道:“它们增加了我们不假思索就能做的事情的数量。而我们不假思索就做的事情——这才是真正的危险所在。”
In summary, the main message remains—and yes, I realize I’ve emphasized this point throughout the book to the point where you could probably recite it in your sleep—that AI output requires the same careful review you would apply to a junior developer’s code. The repetition is intentional, because this principle underpins virtually every aspect of safe and effective AI-assisted development. Whether you’re prototyping, building backends, or implementing security features, this mental model provides the right balance of trust and verification to make AI a powerful ally rather than a risky shortcut. It can write a lot of code fast, but you need to instill security best practices into it and double-check for vulnerabilities. Novelist Frank Herbert put it this way in an often-quoted line from God Emperor of Dune (Putnam, 1981): “They increase the number of things we can do without thinking. Things we do without thinking—there’s the real danger.”
使用人工智能可能会让你放松警惕,减少对常规代码的思考,但你应该有意识地思考如何运用安全审查的思维方式。这一点至关重要。抓住那些“我们不假思索就能做到的事”。
Using AI can lull you into doing less thinking about routine code, and you should be consciously thinking about how to apply a security-review mindset. It’s crucial for catching those “things we can do without thinking.”
鉴于上述漏洞类型,如何才能有效地审核和保护我们的人工智能生成的代码?本节将介绍几种你可以采用的技巧和工具。
Given the types of vulnerabilities outlined, how can you effectively audit and secure our AI-generated code? This section looks at several techniques and tools you can employ.
静态分析工具(SAST)可以扫描您的代码已知漏洞模式;例如:
Static analysis tools (SASTs) can scan your code for known vulnerability patterns; for example:
ESLint + 安全插件可以检测 JavaScript 和 Node 代码中的不安全函数或未经清理的输入。
ESLint + security plug-ins can detect insecure functions or unsanitized input in JavaScript and Node code.
Bandit for Python 可以标记生产环境中的 assert 使用情况、弱加密、硬编码密钥等等。
Bandit for Python can flag uses of assert in production, weak cryptography, hard-coded secrets, and more.
GitHub CodeQL允许您在整个代码库中运行查询,以查找 SQL 注入、XSS 和其他常见模式。
GitHub CodeQL lets you run queries across your codebase to find SQL injection, XSS, and other common patterns.
Semgrep拥有多种语言的规则,包括社区维护的 JavaScript、Python、Java、Go 等语言的规则,并且可以开箱即用地发现主要问题。
Semgrep has rules for many languages, including community-maintained ones for JavaScript, Python, Java, Go, and more, and can spot top issues out of the box.
您可以将这些工具集成到您的 CI/CD 或开发流水线中。用它们来测试 AI 生成的代码——虽然它不能检测出所有错误,但很可能会标记出明显的错误(例如,明文密码检查、未过滤的 SQL、不安全的加密)。这相当于一道可靠的安全屏障。
You can integrate these tools into your CI/CD or dev pipelines. Run them on your AI-generated code—it won’t catch everything, but it will probably flag the obvious mistakes (e.g., plain-text password checks, unsanitized SQL, insecure crypto). It’s a solid safety net.
有两种不同的方法可以利用人工智能对生成的代码进行安全审查,每种方法都有其独特的优势。第一种方法是使用生成代码的同一个AI模型,让它切换视角并审核自身的输出。生成代码后,你可以像这样提示模型:
Two distinct approaches can leverage AI for security review of generated code, each with unique advantages. The first involves using the same AI model that generated the code, asking it to switch perspectives and audit its own output. After generating code, you can prompt the model with something like this:
请检查此代码是否存在安全漏洞,并解释您发现的任何问题。
Review this code for security vulnerabilities and explain any issues you find.
这种方法通常会产生令人惊讶的有效结果,因为该模型可以识别常见的安全问题,例如明文密码存储、缺少输入验证或潜在的 SQL 注入漏洞。
This approach often yields surprisingly effective results, as the model can identify common security problems such as plain-text password storage, missing input validation, or potential SQL injection vulnerabilities.
第二种方法是采用不同的AI模型作为独立审查员。例如,如果您使用ChatGPT生成代码,您可以将该代码粘贴到Claude或Gemini中进行安全分析。这种跨模型审查可以揭示不同的视角,并发现原始模型可能忽略的问题,就像不同的安全工具或人工审查员会带来不同的专业知识和关注领域一样。不同的模型可能使用不同的侧重点或数据集进行训练,因此可能会发现不同类型的漏洞。
The second approach employs a different AI model as an independent reviewer. For instance, if you generated code using ChatGPT, you might paste that code into Claude or Gemini for security analysis. This cross-model review can surface different perspectives and catch issues the original model might have overlooked, much like how different security tools or human reviewers bring varying expertise and focus areas. Different models may have been trained with different emphases or datasets, potentially catching distinct categories of vulnerabilities.
这两种技术都能作为宝贵的额外安全审查层级,它们可以补充而非取代正规的安全测试和人工专家。虽然人工智能审查员偶尔可能会误报或遗漏一些细微的漏洞,但它们在快速发现常见的安全反模式方面表现出色。您可以将此过程视为专门针对安全考量的自动化结对编程。关键在于将这些人工智能生成的安全审查结果视为安全评估流程的补充输入,而不是最终的安全许可。
Both techniques serve as valuable additional layers of security review, complementing but never replacing proper security testing and human expertise. While AI reviewers may occasionally flag false positives or miss subtle vulnerabilities, they excel at catching common security antipatterns quickly. Think of this process as automated pair programming focused specifically on security considerations. The key lies in treating these AI-generated security reviews as another input to your security assessment process rather than as definitive security clearance.
如果你是在团队中,拥有清单审查代码时要注重安全性。人工智能生成的代码通常能够“正常运行”,但并未针对恶意攻击进行加固。对于人工智能生成的代码,务必考虑以下几点:
If you’re in a team, have a checklist for reviewing code with an eye to security. AI often produces code that “works” for the expected case but isn’t hardened to deal with malicious cases. For AI-generated code, be sure to consider:
身份验证流程:它们可靠吗?
Authentication flows: Are they solid?
任何数据进入系统的地方:我们是否对输入进行验证?
Any place data enters the system: Are we validating inputs?
数据离开系统的任何地方:我们是否对输出进行清理?我们是否保护敏感数据?
Any place data leaves the system: Are we sanitizing outputs? Are we protecting sensitive data?
外部 API 的使用:我们是否处理了故障?我们是否公开了密钥?
Use of external APIs: Are we handling failures? Are we exposing keys?
数据库访问:我们是否安全地使用了 ORM?我们是否使用了参数化查询?
Database access: Are we using ORMs safely? Are we using parameterized queries?
底层代码中的内存管理:如果人工智能使用 C/C++ 或 Rust 编写代码,是否存在内存溢出?是否存在内存滥用?
Memory management in low-level code: If AI is writing C/C++ or Rust, are there overflows? Is there any misuse?
采用动态方法。对于模糊测试,向函数或端点输入随机或专门设计的输入,看看它们是否会崩溃或出现奇怪的行为。AI 可以帮助生成模糊测试案例,或者您可以使用现有的模糊测试工具,例如Google 的 OSS Fuzz。
Use dynamic approaches. For fuzz testing, feed random or specially crafted inputs into your functions or endpoints to see if they break or do weird things. AI can help generate fuzz cases, or you can use existing fuzz tools, such as OSS Fuzz by Google.
运行诸如 OWASP ZAP 之类的渗透测试工具反对您的AI生成的Web应用程序可以自动扫描XSS和SQL注入等漏洞。例如,ZAP可以尝试注入脚本并使其生效,从而检测出某些输入未经清理。
Running penetration-testing tools like OWASP’s ZAP against your AI-made web app can automate scanning for things like XSS and SQL injection vulnerabilities. For example, ZAP might attempt to inject a script and get it reflected, and detect that a certain input isn’t sanitized.
如果你正在构建 API,可以使用 Postman 之类的工具。或者,自定义脚本可以尝试发送格式错误的数据,看看系统会如何反应:是抛出 500 错误还是优雅地处理错误?
If you’re building an API, tools like Postman or custom scripts can try sending ill-formed data to see how the system behaves: does it throw a 500 error or handle errors gracefully?
对于关键代码片段,编写测试来验证其安全属性。例如,您可以测试登录速率限制器是否会在 X 次错误尝试后"<script>alert(1)</script>"触发,或者某些输入(例如 `<input type="file">`)是否会在响应中进行转义。要测试未经授权的用户是否无法访问受保护的资源,请模拟已授权和未授权的调用,并确保应用程序行为正确。
For critical pieces of code, write tests that assert security properties. For instance, you might test that your login rate limiter triggers after X bad attempts, or that certain inputs (like "<script>alert(1)</script>") come out escaped in the response. To test that unauthorized users cannot access a protected resource, simulate both authorized and unauthorized calls and ensure the app behaves correctly.
你可以让人工智能帮助生成这些测试:
You can ask the AI to help generate these tests:
编写测试以确保未经授权的用户在 /deleteUser 端点收到 403 错误。
Write tests to ensure an unauthorized user gets 403 on the /deleteUser endpoint.
然后运行测试。
And then run the tests.
人工智能模型存在一个直接影响安全性的根本性局限性:它们的知识会冻结在某个特定的时间点。模型完成训练后,无法学习之后发现的漏洞、随后发布的安全补丁或新出现的最佳实践。这种知识断层在人工智能的认知与当前的安全标准之间造成了巨大的鸿沟。
AI models possess a fundamental limitation that directly impacts security: their knowledge freezes at a specific point in time. When a model completes training, it cannot learn about vulnerabilities discovered afterward, security patches released subsequently, or new best practices that emerge. This knowledge cutoff creates a critical gap between what the AI knows and current security standards.
假设一个模型在 2023 年训练,并在 2025 年生成代码。在这期间,大量的安全漏洞被发现、修复并记录在案。新的攻击途径不断涌现,框架也增加了安全功能,最佳实践也在不断发展。然而,除非你在提示中明确提供更新信息,否则人工智能仍然无法感知这些变化。
Consider a model trained in 2023 generating code in 2025. During those intervening years, numerous security vulnerabilities have been discovered, patched, and documented. New attack vectors have emerged, frameworks have added security features, and best practices have evolved. The AI, however, remains unaware of these developments unless you explicitly provide updated information within your prompts.
随着安全标准和漏洞数据库的快速发展,这种局限性变得尤为突出。例如,OWASP Top 10漏洞库会定期更新,以反映不断变化的安全威胁形势。如果你让人工智能“编写一个安全的文件上传功能”,它可能会根据训练数据实施一些合理的保护措施——例如文件类型验证、大小限制以及将文件存储在网站根目录之外。然而,它可能会忽略最近发现的攻击途径,或者未能实施新近推荐的缓解措施。
This limitation becomes particularly acute with rapidly evolving security standards and vulnerability databases. The OWASP Top 10, for instance, undergoes periodic updates to reflect the changing threat landscape. If you prompt an AI to “write a secure file upload function,” it might implement reasonable protections based on its training data—perhaps including file type validation, size limits, and storage outside the web root. However, it could miss recently discovered attack vectors or fail to implement newly recommended mitigations.
解决方案在于主动利用最新的安全信息来补充人工智能的知识。在请求安全敏感代码时,请在提示中包含对当前最佳实践的参考。例如,与其简单地请求安全代码,不如提示:
The solution involves actively supplementing the AI’s knowledge with current security information. When requesting security-sensitive code, include references to current best practices in your prompts. For example, rather than simply asking for secure code, you might prompt:
编写一个文件上传函数,解决 2025 年 OWASP Top 10 中的安全问题,尤其要关注注入攻击和服务器端请求伪造。
Write a file upload function that addresses the security concerns in the 2025 OWASP Top 10, particularly focusing on injection attacks and server-side request forgery.
这种方法使人工智能的响应基于当前的安全标准,而不是可能过时的训练数据。
This approach grounds the AI’s response in current security standards rather than potentially outdated training data.
同样,框架特定的安全特性通常在人工智能训练完成之后才会出现。例如,Express.js 应用程序可以从Helmet 中间件中受益匪浅,该中间件可以设置安全标头。在 Helmet 成为标准实践之前训练的 AI 可能会生成缺少这一关键安全层的 Express 应用程序。通过在提示中明确提及当前的安全工具和实践,您可以帮助 AI 生成符合当代安全标准而非历史标准的旧代码。
Similarly, framework-specific security features often emerge after an AI’s training cutoff. Express.js applications, for instance, benefit significantly from the Helmet middleware for setting security headers. An AI trained before Helmet became standard practice might generate Express applications without this crucial security layer. By explicitly mentioning current security tools and practices in your prompts, you help the AI generate code that aligns with contemporary security standards rather than historical ones.
确保代码(人工智能和人工)具有良好的日志记录功能,尤其是在关键操作或潜在故障点附近。这有助于调试生产环境中的问题。如果 AI 生成的代码段日志信息很少,请考虑添加更多日志。例如,如果 AI 生成的 catch 代码块只是简单地捕获错误,请将其修改为记录错误信息(以及一些上下文信息),以提高可见性。此外,请对日志进行脱敏处理,确保其中不包含任何敏感信息。
Ensure that the code (AI and human) has good logging, especially around critical operations or potential failure points. This helps in debugging issues in production. If an AI wrote a section with minimal logs, consider adding more. For example, if there’s an AI-generated catch block that just swallows an error, change it to log the error (and maybe some context) for visibility. Also, sanitize the logs so they contain no sensitive info.
一些人工智能编码工具旨在将代码生成与内置安全扫描相结合。Snyk 就是一个典型的例子:它采用了一种混合方法,将 LLM 生成的建议与基于规则的污染分析相结合。据 Snyk 称,当您请求代码时(即使是来自 OpenAI、Anthropic 或 Hugging Face 等 LLM 库),Snyk Code 会跟踪潜在的不安全数据流,并在不可信的输入到达敏感目标之前将其标记出来。实际上,这意味着如果 AI 建议数据库查询,Snyk 会确保其参数化,从而防止 SQL 注入——即使您自己忘记这样做。这类工具尤其有用,因为它能有效避免通过 AI 生成的建议引入不安全的代码。
Some AI coding tools aim to blend code generation with built-in security scanning. Snyk is a prime example: it uses a hybrid approach combining LLM-generated suggestions with rule-based taint analysis. According to Snyk, when you request code (even from LLM libraries like OpenAI, Anthropic, or Hugging Face), Snyk Code tracks potentially unsafe data flows and flags untrusted inputs before they reach sensitive sinks. In practice, that means if an AI suggests a database query, Snyk ensures it’s parameterized, preventing SQL injection—even if you forget to do so yourself. This kind of tool is particularly useful because it works to avoid introducing insecure code through AI-generated suggestions.
如果你使用的是集成开发环境(IDE),通常会看到警告或波浪线来突出显示可疑代码。现代集成开发环境(IDE)配备智能感知功能,有时可以检测到可疑的 SQL 字符串拼接。不要因为这些警告和标记是由 AI 生成的就忽略它们——务必解决问题。AI 在生成代码时无法获得这些实时警告。
If you’re using an IDE, often you’ll see warnings or squiggly lines to highlight suspicious code. Modern IDEs with IntelliSense can sometimes catch, for instance, a string concatenation of SQL that looks suspicious. Don’t ignore those warnings and flags just because the AI writes them—address the issue. The AI doesn’t have the benefit of those real-time warnings when generating the code.
使用 AI 快速生成大量代码后,在进行审核时,要转换思路,放慢速度。当你能够快速开发新功能时,很容易急于求成,但务必安排时间进行彻底的审查。可以将其理解为“AI加速开发,人工加速安全”。Snyk 的最佳实践建议直接在集成开发环境 (IDE) 中扫描 AI 代码,并提醒用户不要让 AI 的速度超过安全检查的速度。换句话说,将安全扫描集成到您的开发流程中,以便在编写代码后立即发现漏洞。
After using AI to generate a lot of code quickly, shift gears and slow down when it’s time for auditing. When you can produce features fast, it’s tempting to chase the next one, but schedule time for a thorough review. Think of it as “AI-accelerated development, human-accelerated security.” Snyk’s best practices recommend scanning AI code right in the IDE, and caution against letting AI’s speed outpace your security checks. In other words, integrate security scanning into your dev loop, so you can catch vulnerabilities as soon as the code is written.
总之,在审核人工智能生成的代码时,您会用到许多与传统开发中相同的工具——静态分析、动态测试、代码审查——但您可能需要更频繁地使用这些工具,因为代码生成速度更快。务必将每一份人工智能输出都视为需要检查的对象。
In summary, when you audit AI-generated code, you’ll use many of the same tools you use in traditional development—static analysis, dynamic testing, code review—but you might apply them more frequently, because code is produced more quickly. Treat every AI output as needing inspection.
安全性是可靠性的一个支柱,而更广泛的概念则涵盖了软件系统的基本可靠性。 从软件架构的角度来看,可靠性解决的是关于系统故障及其后果的关键问题。您的系统是否需要具备故障安全保障?它是否至关重要,甚至可能影响人身安全?如果系统发生故障,是否会给您的组织造成重大经济损失?这些因素决定了您在开发和测试实践中需要达到的严谨程度。
While security forms one pillar of reliability, the broader concept encompasses the fundamental dependability of your software system. Reliability, in software architecture terms, addresses critical questions about system failure and its consequences. Does your system need to be fail-safe? Is it mission critical in ways that could affect human lives or safety? If the system fails, will it result in significant financial losses for your organization? These considerations determine the rigor required in your development and testing practices.
在人工智能辅助开发过程中,这些可靠性要求依然不变。由人工智能辅助生成的银行应用程序与完全由人工编写的应用程序一样,对交易准确性和数据完整性有着相同的要求。医疗保健系统无论其代码来源如何,都必须满足相同的患者安全标准。人工智能参与代码生成并不会降低这些基本的可靠性要求。
When you’re building with AI assistance, these reliability stakes remain unchanged. A banking application generated with AI assistance carries the same requirements for transaction accuracy and data integrity as one written entirely by humans. A healthcare system must meet identical standards for patient safety regardless of how its code originated. The AI’s involvement in code generation does not diminish these fundamental reliability requirements.
这一现实凸显了全面测试在人工智能辅助开发中的重要性。强大的测试框架能够确保代码正确执行预期功能,并在项目演进过程中保持这种正确性。虽然测试人工智能生成的代码遵循与测试人类编写的代码相同的基本原则,但人工智能开发过程中涌现出的某些细微差别和机遇值得特别关注。
This reality underscores why comprehensive testing becomes even more critical in AI-assisted development. A strong testing framework ensures that your code performs its intended functions correctly and maintains that correctness as the project evolves. While testing AI-generated code follows the same fundamental principles as testing human-written code, certain nuances and opportunities emerge from the AI development process that warrant specific attention.
以下各节将探讨如何利用 AI 不仅生成代码,而且创建强大的测试套件,以验证可靠性、维护系统稳定性,并确保您的软件在关键时刻能够正确运行。
The following sections explore how to leverage AI not just in generating code but in creating robust test suites that validate reliability, maintain system stability, and provide confidence that your software will perform correctly when the stakes are highest.
首先,要尽早并频繁地采用自动化测试。开发进度缓慢时,为了尽快推出新功能,很容易忽略测试编写。讽刺的是,当开发速度加快(借助人工智能)时,也容易忽略测试,因为新功能层出不穷。但当代码快速迭代时,恰恰是最需要测试来发现回归或集成问题的时候。因此,在借助人工智能实现某个功能后,要养成立即为其编写测试的习惯(甚至可以使用人工智能来编写这些测试)。这不仅可以验证功能的有效性,还能在后续修改时保护其安全。
First, embrace automated testing early and often. It’s easy to skip writing tests when development is slow because you want to push features. Ironically, when development is fast (with AI), it’s also easy to skip tests, because new features keep coming at you. But when code is churned out rapidly, that’s precisely when you most need tests to catch regression or integration issues. So after implementing a feature with AI help, get into the habit of immediately writing tests for it (or even using AI to write those tests). This verifies the feature and also guards it as you change things later.
2022 年的一项研究发现,使用人工智能助手的开发者对自己编写的代码安全性更有信心,即使这些代码客观上不如未使用人工智能助手的开发者编写的代码安全。你需要通过实际测试来消除这种过度自信。
A 2022 study found that developers who were using an AI assistant were more confident in the security of the code they wrote even when it was objectively less secure than code written by those without AI assistance. You need to counteract that overconfidence with actual tests.
正如我在第四章中提到的,人工智能不仅可以用于生成代码,还可以用于生成一系列测试用例。这样,人工智能就能帮助自身进行二次检查。这就像让它同时完成实现和初步验证一样。例如,编写完一个新模块后,你可以问:
As I noted in Chapter 4, you can use the AI not just to generate the code but also to produce a suite of tests. This way, AI helps double-check itself. It’s like having it do both the implementation and an initial pass at validation. For example, after writing a new module, you could ask:
为该模块编写单元测试,覆盖所有边界情况。
Write unit tests for this module, covering edge cases.
如果测试通过,那就太好了。如果测试失败,要么是代码有漏洞,要么是测试预期结果与实际情况不符。请调查并修复代码或进行相应的测试。
If they pass, great. If they fail, either there’s a bug or the tests expected something else. Investigate and fix either code or test as appropriate.
要谨慎,人工智能可能会错误地假设某些输出或行为;应将其测试结果(如同其代码一样)视为建议,而非最终结果。您可能需要调整测试的预期结果以匹配预期行为——但即使是这个过程也很有价值,因为它能迫使您清晰地定义预期行为。
Be cautious that the AI may assume some output or behavior incorrectly; treat its tests, like its code, as suggestions, not the ground truth. You might need to adjust the test’s expectations to match the intended behavior—but even that process is valuable, because it forces you to define the intended behavior clearly.
将测试套件集成到持续集成 (CI) 流水线中,并在每次提交时运行。这样,每当添加或更改 AI 生成的代码时,所有测试都会自动运行。如果出现问题,您可以及早发现。有时,AI 可能会引入一些细微的破坏性更改(例如稍微更改函数签名或输出格式),而一个强大的测试套件可以检测到这些更改。同时,在 CI 中加入安全扫描(例如npm audit静态分析),以便标记任何新引入的风险模式。可以尝试的测试类型包括:
Incorporate your test suite into a CI pipeline that runs on every commit. This way, whenever AI-generated code is added or changed, all tests run automatically. If something breaks, you’ll catch it early. Sometimes AI might introduce subtle breaking changes (like changing a function signature or output format slightly), and a robust test suite will detect that. Include security scans in the CI too (like npm audit or static analysis) so that any new introduction of a risky pattern is flagged. Types of tests to try include:
基于属性的测试(例如使用 Python 的 Hypothesis或JavaScript 的 fast-check等工具)是另一种很有价值的技术。与其编写具有特定输入和预期输出的单个测试用例,不如定义代码应始终满足的高级属性。然后,该框架会生成各种输入,以检查这些属性是否成立。
Property-based testing (with tools like Hypothesis for Python or fast-check for JavaScript) is another valuable technique. Instead of writing individual test cases with specific inputs and expected outputs, you define high-level properties that your code should always satisfy. The framework then generates a wide range of inputs to check whether those properties hold.
以排序为例。与其断言结果如何sort([3, 1, 2]) === [1, 2, 3],不如定义属性:
输出结果应按顺序排列。
它应该包含与输入相同的元素。
然后,该工具会生成数十个或数百个输入数组来测试这些条件,并找到您可能手动想不到的极端情况。
Take sorting as an example. Rather than asserting that sort([3, 1, 2]) === [1, 2, 3], you can define properties:
The output should be in order
It should contain the same elements as the input
The tool then generates dozens or hundreds of input arrays to test those conditions—and finds edge cases you might not think of manually.
这对于人工智能生成的代码尤其有用。如果你的人工智能编写了一个函数来规范化电子邮件地址(例如,将域名转换为小写),属性测试可以检查输出是否幂等——也就是说,运行该函数两次是否与运行一次得到相同的结果。如果某个极端情况违反了该不变性,测试框架将生成一个反例来帮助您诊断错误。
This can be especially useful for AI-generated code. If your AI writes a function to normalize email addresses (such as by lowercasing the domain), a property test might check that the output is idempotent—meaning running the function twice gives the same result as running it once. If an edge case violates that invariant, the test framework will generate a counterexample to help you diagnose the bug.
人工智能可能会编写未优化的代码。因此,在负载下测试系统是一个好习惯。这是性能方面的可靠性。使用 JMeter、Locust 或 k6 等工具模拟大量请求或大数据,看看系统是否能够承受。如果不能,则找出瓶颈所在。
AI might write code that’s not optimized. It’s a good idea to test your system under load. This is reliability in terms of performance. Use tools like JMeter, Locust, or k6 to simulate many requests or heavy data and see if the system holds up. If not, identify the bottlenecks.
例如,人工智能可能编写了一个简单的O(n^2)算法,处理 100 个项目时运行良好,但处理 10,000 个项目时就会崩溃。如果没有性能测试,你可能要等到系统上线后才会发现这个问题。因此,如果适用,请加入一些性能测试场景。测试一些关键操作在输入规模不断增加时的运行时间,或者使用性能分析工具来查看 CPU 时间和内存占用情况,尤其是在处理繁重任务时。
For instance, maybe the AI writes a naive O(n^2) algorithm that works fine on 100 items but will tank at 10,000. Without performance tests, you might not notice that until it’s in production. So incorporate some performance scenarios, if applicable. Time some critical operations with increasing input sizes, or use profiling tools to see where CPU time or memory goes for heavy tasks.
人工智能在编写代码时可能不会主动考虑到这些故障模式,因此您需要进行测试并加以改进。测试这些场景可以提示您添加适当的回退逻辑、重试机制或用户反馈,从而提高可靠性。
Intentionally cause errors to ensure the system responds gracefully, such as:
For an API, shut down the database and see if the API returns a friendly error or crashes. If it crashes, add code (or ask AI to add code) to handle DB connection errors.
For the frontend, simulate the backend returning 500 errors and ensure the UI shows an error message, not a blank page or infinite spinner.
AI might not think of these failure modes on its own when writing code, so you have to test them and then refine. Testing these scenarios will improve reliability by prompting you to add proper fallback logic, retries, or user feedback.
加入日志记录功能,并可能在测试中使用日志进行验证。例如,如果某个操作应该触发审计日志条目,则需要进行测试。人工智能可以生成日志行;验证它们是否按预期输出。
Incorporate logging and perhaps use the logs in tests for verification. For instance, if a certain action should trigger an audit log entry, test for that. AI can generate log lines; verify they print out as expected.
此外,还要考虑设置监控(例如,在内存中模拟如何在生产环境中监控您的服务)。 例如,您可以跟踪测试运行期间是否记录了任何未捕获的异常。如果记录了,则将其视为测试失败;这意味着某些情况未得到正确处理。
Also, think about setting up monitoring (like an in-memory simulation of how your service will be monitored in production). For example, you might track if any uncaught exceptions are logged during test runs. If yes, treat it as a test failure; that means there’s some case not properly handled.
可维护性测试,例如确保代码风格和规范非常重要。使用代码检查工具和格式化工具来保持代码一致性,因为人工智能可能会根据不同的提示生成略有不同的代码风格。像Prettier或Black(用于 Python)这样的格式化工具可以统一代码风格。为了保持逻辑一致性,并找出可能需要重构的过于复杂的 AI 生成代码,可以考虑添加代码检查规则,例如强制执行函数复杂度限制。(更多信息请参阅“确保 AI 加速代码库的可维护性” 。)
Maintainability testing, like ensuring code style and standards, is important. Use linters and formatters to keep code consistent, since AI can produce slightly different styles from different prompts. A formatting tool like Prettier or Black (for Python) can unify style. For more logical consistency and to catch overly complex AI-generated code that might need refactoring, consider adding linting rules that enforce things like function complexity limits. (See “Ensuring Maintainability in AI-Accelerated Codebases” for more.)
测试完成后,你就可以更有信心地重构 AI 代码了。或许人工智能会提供一个可行但略显笨拙的解决方案;你可以对其进行改进,并通过测试来确保没有破坏其正常行为。你甚至可以要求人工智能重构自身的代码:
Once your tests are in place, you can refactor AI code more confidently. Perhaps the AI produces a working but clunky solution; you can improve it and rely on tests to ensure you haven’t broken its behavior. You might even ask AI to refactor its own code:
重构此函数,使其更清晰易懂,同时保持其能够通过现有测试。
Refactor this function for clarity while keeping it passing the current tests.
如果你的测试没问题,你可以检查重构是否破坏了任何东西。
If your tests are good, you can check that the refactoring didn’t break anything.
要理解人工智能系统中的非确定性,需要区分两种截然不同的场景。当人工智能在生产系统中运行时,例如聊天机器人回复客户咨询或推荐引擎个性化内容时,即使输入完全相同,输出结果也可能存在差异。这种差异源于模型温度设置、随机种子或模型状态演变等因素。测试此类系统需要采用专门的方法,考虑可接受的偏差范围,而不是期望结果完全一致。
Understanding nondeterminism in AI systems requires distinguishing between two fundamentally different scenarios. When AI operates at runtime in production systems, such as a chatbot responding to customer queries or a recommendation engine personalizing content, the outputs can vary even with identical inputs. This variability stems from factors like model temperature settings, random seeds, or evolving model states. Testing such systems requires specialized approaches that account for acceptable variation ranges rather than expecting exact matches.
然而,人工智能辅助代码生成则呈现出完全不同的范式。一旦人工智能生成代码并将其提交到代码库,它就与任何人类编写的代码一样具有确定性。计算税率的函数对于相同的输入每次都会产生相同的输出,无论它最初是由人类还是人工智能编写的。这种确定性对于系统可靠性至关重要,并且使得传统的测试方法完全适用于人工智能生成的代码。
However, AI-assisted code generation presents a different paradigm entirely. Once an AI generates code and that code is committed to your repository, it becomes as deterministic as any human-written code. The function that calculates tax rates will produce the same output for the same input every time, regardless of whether a human or AI originally wrote it. This determinism is crucial for system reliability and makes traditional testing approaches entirely applicable to AI-generated code.
更微妙的挑战在于……集成多个由人工智能生成的组件,每个组件都可能是在各自独立的环境下创建的,并带有不同的隐含假设。以电子商务系统为例,您可以指示人工智能生成一个订单处理模块,并使其处理国际订单。此外,您还要求人工智能为同一系统创建一个运费计算服务。订单处理模块遵循美国惯例,将 12 月 25 日的日期格式设置为“12/25/2024”。而运费计算服务可能受到欧洲惯例的影响,其日期格式为“25/12/2024”。这两个组件单独运行均完美,并通过了各自的单元测试。
The more subtle challenge emerges when integrating multiple AI-generated components, each potentially created in isolation with different implicit assumptions. Consider a concrete example from an ecommerce system. You might prompt an AI to generate an order processing module, instructing it to handle international orders. Separately, you ask the AI to create a shipping calculation service for the same system. The order processing module, following American conventions, formats dates as “12/25/2024” for December 25. Meanwhile, the shipping service, perhaps influenced by European examples in its generation, expects dates formatted as “25/12/2024.” Both components function perfectly in isolation, passing their individual unit tests.
这种不匹配现象仅在集成测试期间订单处理器将日期传递给发货计算器时才会显现。发货服务会将“12/01/2024”解读为1月12日而非12月1日,从而可能导致发货时间完全基于错误的月份计算。这种假设不匹配在人工智能生成的组件中尤为常见,因为人工智能在独立生成每个组件时可能会参考不同的示例或约定。因此,对组件间实际数据流进行全面的集成测试至关重要,以便在这些细微的不兼容性导致生产故障之前将其发现。
The mismatch only surfaces during integration testing when the order processor passes a date to the shipping calculator. The shipping service interprets “12/01/2024” as January 12 rather than December 1, potentially calculating shipping times based on the wrong month entirely. This type of assumption mismatch is particularly common with AI-generated components because the AI might draw from different examples or conventions when generating each piece independently. Comprehensive integration testing that exercises the actual data flow between components becomes essential for catching these subtle incompatibilities before they cause production failures.
人工智能辅助项目的质量保证流程可能需要更多创造性,因为人工智能可能会引入不寻常的极端情况。例如,人工智能可能会输出你未明确考虑到的特征——如果是这样,也需要对其进行测试。如果它添加了隐藏行为,要么将其移除,要么对其进行适当的测试。
The QA process for AI-assisted projects might require a bit more creativity, since AI can introduce unusual edge cases. For instance, an AI might output a feature you didn’t explicitly consider—if so, test that as well. If it added a hidden behavior, either remove it or properly test it.
最后,如果条件允许,请在与生产环境类似的场景下,使用实际的数据负载测试您的应用程序。有时,性能问题只会在数据量较大或并发性较高时才会出现。利用这些测试结果找出效率低下的环节。
Finally, if possible, test your application in an environment similar to production, with a realistic data load. Sometimes performance issues only appear with larger data volumes or higher concurrency. Use those test results to pinpoint inefficiencies.
虽然人工智能经常能编写出正确的代码,但它未必总能编写出最优代码。层级模型本身并不进行性能分析;它们通常只是重现训练数据中的常见现象。因此,务必警惕潜在的性能问题,尤其是在关键路径或大规模应用中。
While the AI often writes correct code, it may not always write optimal code. LLMs don’t inherently do performance analysis; they typically reproduce what is common in their training data. Therefore, be vigilant about potential performance issues, especially in critical paths or for large-scale use.
你甚至可以和人工智能聊天,获取性能优化方面的建议:
You can even chat with the AI for hints about performance optimization:
这段代码的复杂度如何?可以改进吗?
What is the complexity of this code? Can it be improved?
这个功能运行缓慢——有什么办法可以加快它的速度吗?
This function is slow—any ideas on how to make it faster?
它可能并不总是正确的,但有时可以提供有用的建议,或者至少可以证实你的想法。
It might not always be right, but it can sometimes give useful suggestions or at least confirm your thinking.
也就是说,不要过度优化,也不要过早优化或在不需要的地方进行优化。如果数据量较小或操作频率较低,AI 解决方案有时完全可以胜任。利用性能分析数据,专注于真正的瓶颈,并优化真正需要优化的部分。Vibe 编码的优势在于,你无需花费大量时间从零开始编写代码,因此可以允许一些非关键部分保持简单,无需过度优化,只要它们不影响用户体验或成本即可。这种方法符合敏捷实践:先保证功能可用,然后再根据需要优化速度。
That said, don’t overoptimize, and don’t optimize prematurely or where it’s not needed. Sometimes the AI solution is perfectly fine, if the data sizes are small or the operation infrequent. Use your profiling data to focus on real bottlenecks and optimize the parts that really need it. The advantage of vibe coding is that you haven’t spent a ton of time handcrafting code from scratch, so you can afford to let some noncritical parts be simple and not superoptimized, as long as they don’t impact user experience or cost. This approach aligns with agile practices: make it work, then make it fast (if needed).
Here are some areas to cover as you ensure your AI-augmented project runs efficiently:
当人工智能生成算法时,采取请花点时间思考一下它的复杂度。有时,它会使用暴力解法,而实际上存在更高效的算法。例如,它可能会因为忘记了单步排序的方法而对列表进行两次排序,导致复杂度为 O(n log n × 2),而实际上 O(n log n) 就能完成(大写O代表内存使用量)。或者,它可能会使用嵌套循环,导致操作复杂度为 O(n² ),而实际上存在已知的 O(n) 方法。如果您发现类似的问题,请提出改进建议:
When the AI generates an algorithm, take a moment to consider its complexity. Sometimes it will use a brute-force solution where a more efficient algorithm exists. For example, it might double-sort a list because it didn’t recall a single-step method, resulting in O(n log n × 2) where O(n log n) could do (the capital O stands for memory usage). Or it might use nested loops that make an operation O(n2) when there’s a known O(n) approach. If you spot something like that, ask for improvements:
我们能否优化这段代码以避免嵌套循环?或许可以使用集合来进行查找。
Can we optimize this to avoid nested loops? Perhaps use a set for lookups.
The AI often will oblige and give a better solution if you hint at the approach. If not, you might have to implement that part manually.
要找出运行缓慢的函数,请运行性能分析器或使用代表性数据或最坏情况数据测量关键代码路径的执行时间。如果某个函数运行速度过慢,您可以尝试手动优化或借助 AI 辅助进行优化:
To identify slow functions, run a profiler or measure execution time of key code paths with representative or worst-case data. If something is too slow, you can attempt to optimize manually or with AI assistance:
优化这个目前是瓶颈的功能;尽量降低它的复杂性。
Optimize this function, which is currently a bottleneck; try to reduce its complexity.
人工智能可能会为了提升性能而重构代码。请使用测试来确保重构后的代码仍然有效。
The AI might restructure the code for performance. Use tests to make sure it still works.
对于关键算法,编写一个小型基准测试框架。如果人工智能给你一段代码,比如用来计算某个东西,那就用其他方法测试一下,或者至少衡量一下它的性能如何随输入规模的变化。如果需要,你可以考虑用更高效的方式重写这段代码。
For critical algorithms, write a small benchmark harness. If AI gives you a piece of code to, say, compute something, test it against another approach, or at least measure how it scales with input size. You might decide to rewrite in a more efficient way if needed.
人工智能生成的解决方案可能需要更多内存不必要的做法包括:例如,将整个文件读入内存而不是流式传输,从而导致内存占用过大。如果您的应用场景涉及大数据,请检查系统的内存使用情况,并根据需要通过流式传输或分块传输进行优化。例如,如果您需要处理数百万条记录,则需要重构 AI 生成的函数loadAllRecords(),使其分批处理或从数据库流式传输数据。
AI-generated solutions might use more memory than necessary: reading entire files into memory instead of streaming, for example, and thus holding large data structures. If your use case involves big data, check your system’s memory usage and optimize by streaming or chunking if needed. For instance, if you need to process millions of records, you’d want to refactor your AI-generated function loadAllRecords() to process them in batches or stream from the database.
还要检查 AI 生成的代码是否释放了资源。在 Java 或 C# 等语言中,它可能打开了文件或数据库连接,但没有将其关闭。在前端单页应用中,事件监听器可能没有被移除,从而导致内存泄漏。一些工具可以提供帮助(例如 Chrome 开发者工具的内存检查器用于前端,Valgrind 用于 C++ 内存泄漏),但通常阅读代码本身就能解决问题。找出这些问题并进行修复。如果发现未关闭的打开文件句柄,请在finally代码块中添加一个关闭语句。
Also check that the AI-generated code is releasing resources. In languages like Java or C#, maybe it opens a file or DB connection and doesn’t close it. In a frontend single-page app, maybe event listeners aren’t removed, leading to leaks. Tools can help (like Chrome dev tools’ Memory Inspector for frontends or Valgrind for C++ leaks), but often just reading the code helps. Identify these and fix them. If you see an open file handle not closed, add a close in a finally block.
如果您使用的是支持线程或异步的语言,请查找 AI 代码中哪些地方可能使用了单线程,而实际上可以并行执行。AI 可能不会在适当的时候自动使用 async/await,也可能不知道将繁重的 CPU 任务卸载到工作线程。找出这些机会。例如,对于 Node 或 Python 中的 I/O 密集型任务,确保使用异步方式,避免系统阻塞。对于 CPU 密集型任务,AI 或许在代码层面帮助不大,但您可以考虑使用性能更高的语言实现,或者将其卸载到后台任务中执行。
If you’re using languages that support threads or async, look for places where the AI code might be single-threaded when it could be parallel. AI might not automatically use async/await where appropriate, and may not know to offload a heavy CPU task to a worker thread. Identify such opportunities. For example, for I/O-bound tasks in Node or Python, ensure asynchronous usage so that the system doesn’t block. For CPU-bound tasks, maybe the AI can’t help much in code, but you might decide to implement in a more performant language or offload to a background job.
一种常见的性能优化方法AI并非总是会自动添加缓存功能,用于缓存耗时操作的结果。检查一下你的代码:是否重复计算某些内容?如果是,请实现缓存(可以是内存缓存,也可以使用Redis等外部缓存)。你可以提示AI:
A common performance optimization that AI doesn’t always automatically add is to cache results of expensive operations. Look at your code: is it recalculating something repeatedly? If so, implement caching (either in-memory or using an external cache like Redis). You can prompt AI:
为该函数添加缓存,以避免重复计算。
Add caching to this function to avoid redundant calculations.
它可能实现简单的记忆功能,或者建议使用缓存库。
It may implement a simple memorization or suggest using a caching library.
如果您的申请如果系统使用数据库,请检查人工智能生成的查询。它们是否正确使用了索引?也许人工智能编写的查询SELECT *只需要几个列。或者,它获取大量数据以在代码中进行筛选,从而造成性能瓶颈,例如 N+1 查询问题。这些低效之处需要通过向数据库推送更多工作或利用正确的索引来优化。
例如,如果生成的代码findOne在循环中重复调用,导致多次数据库往返,您可以使用 `.` 将其重构为单个批处理查询WHERE id IN (...)。同样,如果 AI 在迁移过程中遗漏了对常用字段创建索引,那么添加这些索引对于维持可接受的性能至关重要。AI 经常会生成功能正确但并非最优的数据库交互,这需要人工专业知识来识别和解决。
If your application uses a database, examine the queries the AI creates. Are they using indexes properly? Perhaps the AI wrote SELECT * where only a few columns are needed. Or it’s fetching extensive data to filter in code, creating performance bottlenecks like the N + 1 query problem. These inefficiencies require optimization by pushing more work to the database or leveraging proper indexing.
For instance, if the generated code calls findOne repeatedly within a loop, resulting in multiple database round trips, you can refactor this into a single batch query using WHERE id IN (...). Similarly, if the AI omitted index creation in a migration for frequently queried fields, adding those indexes becomes essential for maintaining acceptable performance. The AI often generates functionally correct but suboptimal database interactions that require human expertise to identify and resolve.
举例来说。认为AI 为你编写了一个函数,该函数通过简单地连接并排序结果来合并两个已排序的数组:(O(n log n))——尽管它可以使用已知的线性算法来合并两个已排序的列表(例如合并步骤或归并排序,O(n))。在代码审查中,你意识到这对于大型数组来说可能是一个瓶颈,因此你建议 AI 实现线性合并:
To illustrate, let’s take an example. Suppose AI writes you a function that merges two sorted arrays by simply concatenating and sorting the result: (O(n log n))—even though there’s a known linear algorithm it could be using to merge two sorted lists (like merge step or merge sort, O(n)). In code review, you realize this could be a bottleneck for large arrays, so you prompt AI to implement the linear merge:
优化 mergeSortedArrays 函数,使其在不使用内置排序的情况下,以线性时间执行合并操作。
Optimize the mergeSortedArrays function to perform the merge in linear time without using built-in sort.
人工智能识别出这是经典的合并算法并将其写入代码。该解决方案通过了你的测试,恭喜你:你在保证正确性的前提下提升了性能。
The AI recognizes this as the classic merge algorithm and writes it. The solution passes your tests, so congratulations: you gained performance without sacrificing correctness.
AI辅助开发并不会取代性能调优,它只是改变了调优的时机。通常情况下,你会先得到一个正确的解决方案(这非常宝贵),然后再将注意力转向测量和优化特定部分。当你确实需要优化某些方面时,只要你引导它了解你的需求,AI就能提供帮助。
AI-assisted development doesn’t remove the need for performance tuning; it just shifts when you do that tuning. You’ll often get a correct solution first (which is extremely valuable), then turn your attention to measuring and optimizing targeted parts. When you do need to optimize something, the AI can help, as long as you guide it on what you need.
代码库的可维护性描述了随着时间的推移,代码库易于修改、扩展和理解的程度。有些人担心人工智能生成的代码可能杂乱无章或前后不一致,尤其是在多个建议采用不同风格或模式的情况下。本节将介绍几种可用于解决这些问题并保持您的 Vibe 代码项目简洁易维护的实践方法。
A codebase’s maintainability describes how easy it is to modify, extend, and comprehend over time. Some worry that AI-generated code could be messy or inconsistent, especially if multiple suggestions have varying styles or patterns. This section covers several practices you can use to address these concerns and keep your vibe-coded project clean and maintainable.
As you prepare your prompts, a few things to keep in mind:
使用代码检查工具和格式化工具来强制执行一致的样式。如前所述,人工智能有时可能会在不同的输出中使用不同的命名规则或格式。生成代码后,对所有代码运行格式化工具(例如 JavaScript 的 Prettier、Python 的 Black、Go 的 gofmt 等),确保代码符合统一的风格。这大大简化了代码阅读(无需切换风格,从而减轻认知负担)。此外,为项目定义命名规范并严格遵守。如果 AI 的输出结果get_user_data出现在不同的位置fetchUserData,请决定你更倾向于哪种规范(例如,snake_case使用 `a`camelCase还是 `b` 等),并重构代码以统一的风格。
Use linters and formatters to enforce a consistent style. As mentioned, AI might sometimes use different naming conventions or formatting in different outputs. Running a formatter (like Prettier for JS, Black for Python, gofmt for Go, etc.) on all code after generation ensures it conforms to a unified style. This makes reading code much easier (no cognitive load switching styles). Additionally, define naming conventions for your project and stick to them. If the AI outputs get_user_data in one place and fetchUserData in another, decide which convention you prefer (snake_case versus camelCase, etc.) and refactor to one style.
鼓励 人工智能写作模块化代码引导它区分关注点。例如,不要让它编写一个巨大的文件来实现所有功能,而是将工作分解成多个任务:
创建用于用户逻辑的 UserService 类。
创建一个单独的模块用于发送电子邮件。
这样就能形成逻辑上划分清晰的代码库。每个模块职责明确,维护起来也更方便。您可以指导架构设计:
Encourage the AI to write modular code by prompting it to separate concerns. For example, instead of asking it to write one huge file implementing everything, break the work into tasks:
Create a UserService class for user logic.
Create a separate module for sending emails.
This leads to a codebase that’s logically divided. It’s easier to maintain when each module has a clear responsibility. You can guide the architecture:
将数据库访问代码与 API 路由代码放在不同的文件或类中。
Put database access code in a separate file or class from the API routing code.
由于使用人工智能时添加功能非常容易,因此必须防止功能蔓延和代码无序增长。如果没有严谨的架构思维,你的代码库就有可能演变成软件架构师所说的“一团乱麻” :这是一种反模式。代码缺乏清晰的结构或边界。人工智能的介入会加剧这种风险,因为传统上与添加功能相关的摩擦消失了,这可能会加速架构的衰败。
Because it’s so very easy to add features when using AI, it’s crucial to guard against feature creep and code sprawl. Without disciplined architectural thinking, you risk your codebase devolving into what software architects call a big ball of mud: an antipattern where code lacks clear structure or boundaries. This risk intensifies with AI assistance, as the friction traditionally associated with adding features disappears, potentially accelerating architectural decay.
为了解决这个问题,请将人工智能辅助开发建立在成熟的架构模式和原则之上。在指导人工智能时,请明确引用项目遵循的模式:
按照项目中使用的存储库/服务模式添加此新功能。
使用我们在领域层建立的六边形架构来实现这一点。
这种特异性有助于在功能快速积累的情况下保持一致性。
To combat this, ground your AI-assisted development in proven architectural patterns and principles. When instructing AI, explicitly reference the patterns your project follows:
Add this new feature following the repository/service pattern used in the project.
Implement this using the hexagonal architecture established in our domain layer.
This specificity helps maintain consistency even as features accumulate rapidly.
对于寻求更深层次架构基础的开发人员来说,一些基础性教材提供了丰富的参考。 重要指导:
For developers seeking deeper architectural grounding, several foundational texts provide essential guidance:
《设计模式:可重用面向对象软件的要素》(Addison-Wesley,1994 年)由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides(“四人帮”)撰写,仍然是可重用设计解决方案的权威目录。
Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the “Gang of Four”) remains the definitive catalog of reusable design solutions.
Mark Richards 和 Neal Ford 合著的《软件架构基础:工程方法》全面涵盖了跨技术栈的架构模式和原则。
Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Ford offers comprehensive coverage of architectural patterns and principles across technology stacks.
Eric Evans 的《领域驱动设计:解决软件核心的复杂性》(Addison-Wesley,2003 年)提供了将软件设计与业务领域保持一致的关键技术——当 AI 生成必须反映复杂业务逻辑的代码时,这些技术尤其有价值。
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (Addison-Wesley, 2003) provides crucial techniques for aligning software design with business domains—particularly valuable when AI generates code that must reflect complex business logic.
这些资源能帮助您有效地指导 AI 工具,确保生成的代码遵循合理的架构原则,而不是增加技术债务。请记住:AI 擅长实现各种模式,但无法判断哪些模式适合您的具体情况。这种架构判断本质上仍然是人类的职责。
These resources equip you to guide AI tools effectively, ensuring generated code adheres to sound architectural principles rather than contributing to technical debt. Remember: AI excels at implementing patterns but cannot determine which patterns are appropriate for your specific context. That architectural judgment remains fundamentally human.
一旦人工智能响应并生成代码,可维护性就变得至关重要。可使用的技术包括以下几种:
Once the AI responds with generated code, maintainability techniques to use include the following:
必要时,不要犹豫,重构人工智能生成的代码。有时,第一次尝试的结果是正确的,但结构并不理想:例如,AI 可能会编写一个非常长的函数,或者在两处重复编写相同的逻辑。一个常见的挑战是无意中重复编写代码:AI 可能没有意识到两个函数的功能相似,因此都创建了它们。如果您发现相似的代码块,请将其重构为一个。代码检查工具(例如代码检查器)可以检测重复代码(有些工具专门用于检测过于相似的代码)。运行这些工具可以突出显示需要“DRY”(避免重复)的地方。
Don’t hesitate to refactor AI-generated code when needed. Sometimes the first pass is correct but not ideally structured: for example, the AI might write a very long function or duplicate its logic in two places. A common challenge is unintentionally duplicated code: the AI might not realize two functions do similar things and create both. If you notice similar blocks, refactor to one. Tools like code linters can detect duplicates (there are linters for too-similar code). Running those could highlight places to “DRY out” (don’t repeat yourself).
要让 AI 帮助重构代码,您可以这样提示:
To ask the AI to help refactor, you could prompt:
重构这段代码,去除重复部分,提高代码清晰度。
Refactor this code to remove duplication and improve clarity.
它可能创建辅助函数或简化某些逻辑。重构后务必进行测试。
It might create helper functions or simplify some logic. Always test after refactoring.
本章已经涵盖了测试,所以我只想指出,一个好的测试套件会让维护工作变得更容易。当您或其他人在将来修改代码时(可能再次使用人工智能),您的测试会检测出这些更改是否破坏了任何功能,因此您可以安心地重构或更改实现。测试将“它做什么”与“它如何做”解耦,使您能够灵活地维护或改进“它如何做”,而无需改变“它做什么”。
This chapter has already covered testing, so I’ll just note that a good test suite makes maintenance easier. When you or others modify code in the future (possibly with AI again), your tests will catch if the changes break anything, so you can refactor or change implementations with peace of mind. Testing decouples “what it does” from “how it does it,” giving you flexibility to maintain or improve “how” without altering “what.”
有时人工智能可能会使用一些其他开发者可能不知道的巧妙技巧或不太常用的功能。虽然这本身并没有什么不好,但要考虑代码的可维护性:如果普通开发者看不懂这段代码,那就应该简化它。例如,如果人工智能使用了过于简洁的正则表达式或列表推导,可以将其重写成更清晰的循环(或者至少添加注释)。
Sometimes the AI might use a clever trick or less common function that other developers might not know. While that’s not inherently bad, consider maintainability: if an average developer would scratch their head at the code, maybe simplify it. For instance, if AI uses a bit of regex magic or list comprehension that’s too terse, rewrite it in a more explicit loop for clarity (or at least comment it).
同样,试图提供帮助的人工智能可能会过度设计解决方案,例如添加不必要的层。举例来说,也许直接的方法就足够了,但人工智能引入的抽象层却毫无用处。移除它以保持代码简洁明了。更简洁的代码通常更容易维护。
Similarly, an AI trying to be helpful might overengineer a solution, like adding layers that aren’t needed. For instance, maybe a direct approach was fine, but the AI introduced an abstraction that isn’t pulling its weight. Remove it to keep things straightforward. Simpler code is usually easier to maintain.
考虑一下失败时的备用方案。为了例如,如果一个由人工智能编写的组件调用外部 API,而该 API 宕机或返回意外数据,我们是否有备用方案(例如使用缓存数据或默认响应)?实施此类弹性机制(熔断器、带退避机制的重试等)可以增强系统的健壮性。除非被要求,否则人工智能不太可能主动执行这些操作。确保系统能够优雅地处理部分故障。如果可能,一个微服务的宕机不应导致整个应用程序崩溃。使用超时和备用逻辑。
Think about fallback strategies in case of failures. For example, if an AI-coded component calls an external API and that API is down or returns unexpected data, do we have a fallback (like using cached data or a default response)? Implementing such resilience patterns (circuit breakers, retries with backoff, etc.) can make the system more robust. The AI likely won’t do this on its own unless asked. Ensure the system can handle partial failures gracefully. One microservice going down shouldn’t take the whole app down, if possible. Use timeouts and fallback logic.
一旦你对代码满意了,还有一些其他问题需要解决。实践有助于保持其可维护性:
Once you’re satisfied with the code, a few more practices help to keep it maintainable:
确保代码有完善的文档说明。除非被提示,否则人工智能通常只会写很少的评论。您可以通过提示请求文档字符串或注释:
添加注释来解释这段代码中每个部分的作用。
为该函数编写文档字符串。
这些解释可以节省其他读者的时间。人工智能通常能生成相当不错的解释,但有时也会误解一些细微之处,因此请自行核对以确保准确性。
Make sure the code is properly documented. AI often writes minimal comments unless prompted. You can request docstrings or comments with prompts:
Add comments to explain the purpose of each section in this code.
Write a docstring for this function.
These can save future readers time. The AI can usually generate fairly good explanations but sometimes misexplains subtle points, so review for accuracy.
此外,还应考虑为项目维护一份高级文档(例如 README 或设计文档),描述其架构、主要组件等等。大部分内容可以自己编写,但如果需要,人工智能可以帮忙总结代码库。
Also consider maintaining a high-level documentation (like a README or design doc) for the project, describing its architecture, main components, and so on. You can largely write this yourself, but AI can help by summarizing the codebase if needed.
如果你遇到类似“AI总是把这个参数命名为很奇怪的名字”这样的问题,请在开发笔记中记录下来,以便其他人参考。这是新协作环境的一部分。如果只有你一个人使用AI生成的代码,一些小问题没关系——但如果其他人加入项目,他们可能会疑惑:“为什么这个东西叫这个名字?”或许应该统一命名。
If you encounter some quirk like “The AI always names this parameter weirdly,” mention it in your dev notes for others. It’s part of the new collaborative environment. If it’s just you using the AI-generated code, a few quirks are fine—but if others join the project, they might wonder, “Why is this thing named like that?” Perhaps just standardize those names.
从可维护性的角度来看,区分哪些代码是由 AI 生成的,哪些是人工编写的,也很重要。虽然并非必须标注,但有些团队可能会添加注释,例如“于 2025 年 5 月 1 日借助 GPT-4 生成”,以便于追溯。理想情况下,如果您对代码有任何疑问,请在 PR 描述中注明:“使用 ChatGPT 辅助实现了此功能;目前看来运行正常,但请仔细检查错误处理逻辑。”
There’s also an aspect of maintainability in terms of knowing which pieces of code were AI-generated and which were human-written. It’s not strictly necessary to label, but some teams might comment, “Generated with the help of GPT-4 on 2025-05-01” for traceability. Ideally, flag anything you’re unsure about in your PR description: “Used ChatGPT to help with this function; it seems to work, but please check the error-handling logic carefully.”
这并非普遍做法。在代码审查过程中,它可能有所帮助,但如果代码已经过人工审查,现在只是代码本身,那么可能就不需要它了。如果您确实保留了任何文本记录或提示,可以在复杂代码的注释中添加链接:“此算法基于提示 X,通过 GPT-4 推导而来;有关推导过程,请参阅文档。” 审查者无需区别对待(您应该审查所有代码),但了解上下文会有所帮助。例如,如果代码存在某种风格不符或奇怪的惯用语,知道它来自人工智能可能会让审查者意识到这不是作者的有意选择,而是人工智能的产物。
This isn’t a widespread practice. It can be helpful during code review, but you might not need it if a human has already reviewed the code and it’s now just code. If you do keep any transcripts or prompts, you could link them in comments for complicated code: “This algorithm derived via GPT-4, based on prompt X; see docs for derivation.” A reviewer doesn’t need to treat it differently in terms of scrutiny (you should scrutinize all code), but it can help to understand the context. For example, if code has a certain style mismatch or an odd idiom, knowing it came from AI might clue the reviewer in that this isn’t a deliberate authorial choice but an AI artifact.
如果你在团队中工作,所有团队成员都应该审查代码——即使代码是由一个人和人工智能共同编写的。它们可能会发现不协调的模式或违反团队规范的地方。随着时间的推移,你会逐渐掌握如何引导 AI 遵循团队的风格(例如在系统提示或初始指南中包含具体信息)。如果多位开发人员使用 AI,请确保每个人都了解所需的风格模式,以便他们能够据此发出提示(例如“使用函数式风格编写”或“使用 async/await,而不是回调函数”)。下一节将介绍一些关于使用 AI 代码进行代码审查的技巧。
If you’re working in a team, have all team members review code—even if one person and AI cowrote it. They might spot awkward patterns or things that break team norms. Over time, you’ll develop a sense of how to prompt the AI to match your team’s style (maybe including specifics in system prompts or initial guidelines). If multiple developers use AI, make sure everyone knows the desired style patterns so they can prompt accordingly (like “Write this in functional style” or “Use async/await, not callbacks”). See the next section for some tips on code review with AI code.
如果在开发过程中,你接受了一个你明知并不理想的AI解决方案,请将其跟踪记录下来。 在评论或项目待办事项中添加技术债务注释:“待办事项:该方案可行,但时间复杂度为 O(n² );如果数据量增长,需要优化。”或“待办事项:为了简化操作,此处使用了全局变量;稍后需要改进。”如果您提出要求,AI 甚至可以自行添加待办事项注释:
If, during development, you accept an AI solution that you know isn’t ideal, track it as technical debt in your comments or the project to-dos: “TODO: The solution works but is O(n2); if data grows, optimize this,” or “TODO: This uses a global variable for simplicity; refine this later.” The AI can even insert TODO comments itself if you ask:
如果有什么方面需要改进,请添加待办事项说明。
If there are any areas that need future improvement, add to-do comments.
最终还是要处理这些待办事项。
Just address those to-dos eventually.
如果人工智能引入了你不熟悉的设计模式或库,请花时间去了解更多相关信息,而不是忽略它。了解特定的缓存方法或其使用的库,将有助于您在未来自信地维护或修改该部分代码。如果它过于晦涩难懂,您可能会选择将其移除,转而使用您熟悉的方案——但有时人工智能会给您带来惊喜,发现一些您之前并不了解的实用库或模式。如果这是一个您和团队可以学习的成熟解决方案,它甚至可以提高代码的可维护性。
If AI introduces a design pattern or library you’re not familiar with, take time to learn more about it rather than ignoring it. Understanding a particular caching approach or a library it uses will help you maintain or modify that part confidently in the future. If it’s too arcane, you might decide to remove it in favor of something you know—but sometimes AI can pleasantly surprise you with a useful library or pattern you didn’t know. If it’s a well-known solution that you and the team can learn, this can even improve maintainability.
实际上,可维护性归根结底还是应用以往的优秀软件工程原则——只不过这次是应用于部分由人工智能编写的代码。幸运的是,由于人工智能减少了繁琐的工作,您可以腾出更多时间专注于代码清理和文档编写,从而提高可维护性。
In practice, maintainability comes down to applying the same good software-engineering principles as always—just applying them to code that was partially written by AI. Fortunately, because AI reduces the grunt work, you may have more time to focus on cleaning up the code and writing docs, which improves maintainability.
一些公司表示,在最初利用人工智能生成大量代码之后,他们会投入时间进行“强化冲刺”,对所有代码进行重构和文档编写。可以考虑采用代码生成密集型冲刺和代码清理冲刺交替进行的方式,作为一种潜在的策略。
Some companies report that after an initial burst of generating code with AI, they invest time in a “hardening sprint” to refactor and document it all. Consider alternating between generation-heavy sprints and cleanup sprints as a potential strategy.
正如第 4 章所讨论的,代码审查是传统开发中的一个关键过程,在 AI 辅助开发中仍然如此。本节讨论当待审查的代码片段由机器生成时需要考虑的一些细微差别。由于人工智能能够快速生成代码,人们担心代码审查会成为瓶颈,这种担忧不无道理——但不要让这种担忧阻碍审查流程。为审查分配充足的时间至关重要。不要想当然地认为“我们写得快,合并也快”。相反,应该更频繁地提交较小的更改,以简化审查流程(这本身就是一个好习惯)。频繁提交较小的拉取请求(PR)比提交一个大型 PR 更容易进行全面审查。如果规划得当,AI 也可以帮助将任务拆分成更小的 PR。
As discussed in Chapter 4, code review is a critical process in traditional development and remains so in AI-assisted development. This section discusses some nuances to consider when a chunk of the code under review is machine-suggested. Because AI can produce code so quickly, it’s reasonable to worry that code review will become a bottleneck—but don’t let that worry hamper the review process. It’s crucial to allocate proper time for reviews. Don’t skimp on the assumption that “we wrote it fast, let’s merge fast.” If anything, commit smaller changes more frequently to make reviews easier (generally a good practice anyway). Frequent, smaller pull requests (PRs) are easier to review thoroughly than one giant PR. The AI can help break tasks into smaller PRs as well, if you plan accordingly.
不要因为“AI 写的,而且测试通过了”就想当然地认为代码是正确的。要批判性地思考,尝试推导出逻辑。如果可能,最好在脑海中进行测试,或者使用提供的测试用例之外的其他用例进行测试,因为测试可能无法覆盖所有情况。你还可以运行代码,甚至可以尝试用一些特殊的输入运行一段代码片段,看看它是否能够正常运行。
Don’t assume code is correct just because “the AI wrote it and the tests pass.” Think critically and try to reason through the logic. If possible, test it mentally or with additional cases outside the provided tests, because tests might not cover everything. You can also run the code and even experiment by running a snippet with a tricky input to see if it behaves.
代码审查也是重要的学习契机。如果人工智能提出了一种新颖且有效的解决方案,审查者在验证其正确性的过程中可能会学到新知识。同样,如果人工智能与人类的合作方案效果欠佳,审查者可以解释更优的实现方式。随着时间的推移,这种反馈循环可以改进团队使用人工智能的方式(例如,帮助每个人理解哪些事情应该避免,或者应该以不同的方式提问)。从某种意义上说,代码审查有助于完善人类的学习循环,因为人类开发者应该学习并理解人工智能编写的任何他们之前不了解的内容。
Code reviews can also be important learning moments. If the AI introduces a novel solution that is actually good, the reviewer might learn something new while verifying its correctness. Similarly, if the AI/human combination does something suboptimal, the reviewer can explain a better approach. Over time, this feedback loop can improve how the team uses AI (like helping everyone understand which things to avoid or ask differently). In a sense, code review helps to close the human learning loop, since the human author should learn and understand anything the AI wrote that is new to them.
代码审查时,首要任务应该是确保代码符合需求和预期设计。这段代码是否实现了预期的功能/缺陷修复?它是否涵盖了规范中提到的所有边界情况?如果提示信息不完整,AI 可能会解决略有不同的问题:它可能处理了不需要的情况,或者遗漏了某些情况。这很正常,但要注意开发人员是否接受了仅部分解决问题的 AI 输出。例如,AI 可能会生成格式化日期的代码,但假定使用某个特定的时区,而这可能符合也可能不符合需求。
When you review code, your first priority should be making sure it meets the requirements and intended design. Does this code do what the feature/bugfix is supposed to? Does it cover any edge cases mentioned in the specifications? If the prompt is off, AI might solve a slightly different problem: maybe it handles a case that wasn’t needed or misses a case. This is normal, but watch that the developer didn’t just accept AI output that only partially addresses the issue. For example, an AI might produce code to format a date but assume a certain time zone, which might or might not align with requirements.
如果代码中某些内容不够清晰,请作者解释其工作原理或这样做的原因。如果他们难以解释,或者敷衍地说“这是AI生成的,我猜是对的”,那就需要引起重视了。团队应该理解代码库中的所有内容。鼓励作者使用AI或查阅文档进行复核,并提供合理的解释,最好是在代码中添加注释。
If something in the code isn’t obvious, ask the author to explain how it works or why it’s done that way. If they struggle to explain or reach for “the AI did it and I assume it’s right,” that’s a red flag. The team should understand everything in the codebase. Encourage the author to double-check with the AI or documentation and provide a proper explanation, possibly as a comment in code.
还要注意本章前面讨论的安全性和性能漏洞,如果违反了任何已知的最佳实践,请指出来——例如,如果输出没有转义(在 Web 开发中),或者如果你在代码中发现凭据。
Pay attention to the security and performance vulnerabilities discussed earlier in this chapter, too, and if any known best practice is violated, call it out—like if output isn’t escaped (in web dev) or if you find credentials in the code.
如果需要,请请求更改或重构。你看到一些代码虽然能运行,但可以更简洁或更符合团队风格:
Request changes or refactoring if you see code that works but could be simpler or more in line with team style:
人工智能为不同的用户角色创建了 3 个独立的功能,这些功能大部分都是重复的。我们能否将它们合并成一个功能,并添加一个角色参数?
The AI created 3 separate functions for different user roles that mostly duplicate each other. Can we merge these into one function with a parameter for role?
代码作者随后可以这样做(或许可以借助人工智能)。如果人工智能的建议没有使用团队统一的代码风格或标准库,也请提及:
The code’s author can then do so (maybe with AI’s help). If the AI suggestion didn’t use the team’s consistent style or standard libraries, mention that too:
我们通常使用 requests 库进行 HTTP 请求,但这段代码使用的是 http.client。为了保持一致性,我们还是使用 requests 库吧。
We usually use the requests library for HTTP calls, but this code is using http.client. Let’s stick to requests for consistency.
然后,作者可以指示人工智能使用首选库进行重写。
The author can then prompt the AI to rewrite using the preferred library.
如果人工智能编写了一些非常复杂的内容,例如复杂的算法,可以考虑与其他审阅者或团队讨论,进行更深入的审阅。
If the AI has written something really complex, like a tricky algorithm, consider discussing it with another reviewer or the team for a deeper review.
您可以尝试一些新兴的、利用人工智能辅助代码审查的工具,例如 GitHub 的 Copilot for Pull Requests,它可以生成摘要并标记潜在的错误和其他问题。这类工具可能会突出显示类似“此代码片段与模块 X 中的代码片段相似,但略有不同”的信息(指出可能存在的重复代码)。这些提示可以作为人工审核的补充,但不应取代人工审核。
You may want to try some of the emerging tools that use AI to assist in code review—like GitHub’s Copilot for Pull Requests, which can generate summaries and flag potential bugs and other issues. Such a tool might highlight something like “This code snippet is similar to one in module X with slight differences” (pointing out possible duplication). These hints can complement the human review but should not replace it.
最后,即使代码存在因人工智能导致的缺陷,在代码审查过程中也要保持尊重和建设性。避免将可能是人工智能造成的问题归咎于开发者:虽然他们仍然对自己的代码负责,但也要理解其背景。人工智能只是一种工具,作者和审查者都在使用它。我们的目标是改进代码并分享知识,而不是互相指责。例如:“这部分代码似乎存在安全问题——很可能是人工智能建议的疏忽;我们来修复一下。”
Finally, be respectful and constructive in your reviewing, even when the code has flaws due to AI. Avoid blaming the developer for what could be an AI artifact: while they are still responsible for their code, recognize the context. AI is a tool, and both author and reviewer are working with it. The goal is to improve the code and share knowledge, not point fingers. For example: “This part seems to have a security issue—likely an oversight from the AI suggestion; let’s fix it.”
归根结底,在 Vibe 编码中,代码审查是我们充分发挥人机协作中人类智能优势的方式。这时就需要监督和专业知识来发现人工智能可能遗漏的地方,并确保代码质量始终保持在高水平。同时,这也是团队知识共享的良机,因为在代码审查中讨论代码有助于加深对领域知识以及如何更好地使用人工智能的理解。
Ultimately, code review in vibe coding is how we fully exercise the human intelligence side of the human/AI partnership. It’s where oversight and expertise come in to catch what the AI might miss and to keep the quality bar high. It’s also a knowledge-sharing moment for the team, since discussing code in reviews spreads understanding of both the domain and how to best use AI.
代码审查也正式化了 Grant Gross 在CIO中提出的“开发者即编辑”的概念:审查者是编辑,确保代码精炼且适合生产环境。这与“氛围编码”的概念完美契合,即氛围(AI建议)存在,但人类的判断对其进行完善。
Code review also formalizes the concept of “developers as editors” introduced by Grant Gross in CIO: the reviewer is an editor, making sure the code is polished and fit for production. This aligns perfectly with vibe coding as a concept, where the vibes (AI suggestions) are there but human judgment refines them.
一旦你确定你的代码安全、经过测试且易于维护,你就需要将其部署到生产环境中,并使其保持可靠运行。
Once you know your code is secure, tested, and maintainable, you need to deploy it and keep it running reliably in production.
虽然人工智能辅助开发不会改变软件部署的核心原则,但它确实引入了关于部署速度和运维复杂性的考量。对于那些寻求全面了解部署基础知识的人来说,《DevOps手册》(IT Revolution Press,2016)——由Gene Kim、Jez Humble、Patrick Debois、John Willis和Nicole Forsgren合著——提供了权威指南,涵盖了从持续集成和部署流水线到监控、安全和组织转型等方方面面。当人工智能加速生成可部署代码的能力时,这些基础知识就显得尤为重要,因为这些原则可以确保您的部署实践能够随着开发速度的提升而扩展。
While AI-assisted development doesn’t alter the core principles of software deployment, it does introduce considerations around deployment velocity and operational complexity. For those seeking comprehensive coverage of deployment fundamentals, The DevOps Handbook (IT Revolution Press, 2016), by Gene Kim, Jez Humble, Patrick Debois, John Willis, and Nicole Forsgren, provides the definitive guide, covering everything from continuous integration and deployment pipelines to monitoring, security, and organizational transformation. This foundational knowledge becomes even more critical when AI accelerates your ability to generate deployable code, as the principles ensure your deployment practices can scale with your increased development velocity.
在逐步推进部署的过程中,请考虑以下因素:以下是一些最佳实践:
As you ramp up to deployment, consider the following best practices:
鉴于人工智能发展的快速步伐,一个强大的持续集成/持续部署 (CI/CD) 流水线至关重要。每次提交(无论是否包含 AI 生成的代码)都应该通过自动化流水线进行构建、测试,并最终部署。这可以减少人为错误,并确保所有部署步骤(测试、代码检查、安全扫描)都能持续执行。如果 AI 代码引入了导致构建失败或测试失败的问题,CI 系统会立即发现并解决。此外,自动化 CI/CD 流水线支持快速迭代,因此您可以快速修复 AI 引入的问题并部署更新。
Given the fast pace of AI development, a robust continuous integration/continuous deployment (CI/CD) pipeline is valuable. Every commit (with or without AI-generated code) should be built, tested, and potentially deployed through an automated pipeline. This reduces human error and confirms that all deployment steps (tests, lint, security scans) are consistently run. If AI code introduces something that breaks the build or fails the tests, the CI will catch it immediately. Also, an automated CI/CD pipeline allows for quick iteration, so you can patch any AI-introduced issues and deploy fixes rapidly.
使用基础设施即代码(Terraform、CloudFormation 等)来定义部署环境。虽然与人工智能编码没有直接关系,但它是可靠部署的一部分。你甚至可以使用人工智能来辅助编写 Terraform 脚本,但要像对待其他人工智能代码一样谨慎对待这些脚本,并进行充分的测试,包括在将其应用到生产环境之前先在沙箱环境中进行测试。Yevgeniy Brikman 撰写的《Terraform: Up & Running》(O'Reilly,2022)一书是一个很好的入门读物,它全面介绍了使用 Terraform 进行基础设施即代码 (IaC) 的原则和实践。
Use infrastructure as code (Terraform, CloudFormation, etc.) to define your deployment environment. While not directly related to AI coding, it’s part of reliable deployments. You could even use AI to help write Terraform scripts, but treat those with the same caution and testing as other AI code, including perhaps testing them in a sandbox before applying them to production. A valuable starting point is the book Terraform: Up & Running (O’Reilly, 2022), by Yevgeniy Brikman, which provides a comprehensive introduction to the principles and practices of IaC with Terraform.
采用分阶段推广策略例如,在全面上线生产环境之前,先部署到测试环境或进行金丝雀发布。这样,你就可以在问题影响所有用户之前发现并解决任何疏忽。例如,你可以将一项新的AI 编码功能部署到 5% 的用户,并通过指标和日志监控是否存在任何错误或性能问题。如果一切正常,再将其推广到 100% 的用户。
Use staged rollout strategies like deploying to a staging environment or a canary release before full production rollout. This way, you can catch anything you’ve overlooked before it affects all users. For example, you might deploy a new AI-coded feature to 5% of users and monitor (with metrics and logs) for any errors or performance issues. If all is good, roll it out to 100% of users.
始终要有回滚计划。尽管经过了所有测试和审查,有时仍会出现疏漏。如果新版本出现问题,请做好回滚到上一个稳定版本的准备。如果您使用 Kubernetes 等容器化策略,请保留之前的部署以便快速切换。如果是无服务器功能,请保留旧版本,直到您对新版本充满信心为止。
Always have a rollback plan. Despite all tests and reviews, sometimes things slip through. If a new release goes wrong, be ready to revert to the last stable version. If you’re using a containerization strategy like Kubernetes, maintain previous deployments for quick switchback. If it’s a serverless function, keep the previous version alive until you’re confident in the new one.
使用 Sentry 等工具跟踪错误并捕获异常。如果 AI 代码在生产环境中抛出意外错误(可能是未涵盖的极端情况),您将收到警报以便及时修复。
使用应用程序性能监控 (APM) 等性能监控工具来跟踪响应时间、吞吐量和内存使用情况。这将显示新部署中的哪些代码导致了性能下降或内存泄漏。
监控可用性:例如,ping 服务端点以确认其是否正常运行。如果出现故障(可能是由于某些未经测试的情况),则应发出警报,以便您可以快速做出反应。
Set up comprehensive monitoring in production, of both system metrics and application logs:
Use tools like Sentry to track errors and capture exceptions. If the AI code throws an unexpected error in production (perhaps an edge case wasn’t covered), you’ll get an alert so you can fix it.
Use performance-monitoring tools like application performance monitoring (APM) to track response times, throughput, and memory usage. This will show you if any code in the new deployment has introduced a slowdown or memory leak.
Monitor availability: for instance, ping the service endpoints to confirm they’re up. If something crashes (maybe due to some untested scenario), an alert should fire, so you can react quickly.
确保在部署过程中妥善处理 API 密钥等机密信息。例如,如果你的 AI 编写的代码需要环境变量中的密钥,请在 CI/CD 或云配置中设置该密钥,以免意外记录或泄露。使用HashiCorp Vault(HashiCorp Vault 提供密钥管理、密钥管理等功能,并支持多种集成)或AWS Secrets Manager(AWS Secrets Manager 允许您安全地存储和轮换数据库凭证、API 密钥和令牌等密钥,并且可以与 GitHub 等 CI/CD 工具集成)等密钥管理工具。此外,如果您使用容器镜像,请对其进行漏洞扫描。
Make sure that secrets like API keys are handled properly in deployment. For example, if your AI wrote code that expects a secret in an environment variable, set up that secret in the CI/CD or cloud config, so it’s not accidentally logged or exposed. Use secret management tools like HashiCorp Vault (HashiCorp Vault offers secrets management, key management, and more with many integrations) or AWS Secrets Manager (AWS Secrets Manager allows you to securely store and rotate secrets like database credentials, API keys, and tokens, and can integrate with CI/CD tools like GitHub). Also, if you’re using container images, scan them for vulnerabilities.
对于重大变更,请考虑蓝绿部署。这需要搭建两个完全相同的生产环境:“蓝色”(当前运行版本)和“绿色”(新版本)。初始阶段,流量会导向蓝色环境。待绿色环境准备就绪并通过测试后,流量才会切换到绿色环境。如果绿色环境出现任何问题,流量可以快速重定向回蓝色环境,从而最大限度地减少停机时间和风险。这种方法可以在新版本正式上线之前,在完整的生产环境中对其进行全面测试。
For major changes, consider a blue-green deploy. This involves setting up two identical production environments: “blue” (the current live version) and “green” (the new version). Traffic is initially directed to the blue environment. Once the green environment is ready and tested, traffic is switched over to it. If any issues arise with the green environment, traffic can be quickly rerouted back to the blue environment, minimizing downtime and risk. This method tests the new version in a full production setting before making it the sole live version.
或者,如果某个特定的 AI 编码算法更改存在风险,或者你想在不影响用户的情况下用真实世界的数据验证其行为,你可以进行影子测试。这涉及到将新版本与当前生产版本并行部署。两个版本会并行接收真实的生产环境输入数据。但是,用户只能看到当前版本的输出。新版本(影子版本)的输出会被收集并与当前版本的结果进行比较,以评估其性能、准确性和稳定性。如果影子版本的结果令人满意且性能良好,则可以放心地将其切换为活动版本。
Alternatively, if a specific AI-coded algorithm change is risky or you want to validate its behavior with real-world data without impacting users, you could shadow test it. This involves deploying the new version alongside the current live version. Real production inputs are fed to both versions in parallel. However, only the current version’s outputs are shown to users. The outputs from the new (shadow) version are collected and compared against the current version’s results to evaluate its performance, accuracy, and stability. If the shadow version’s results are satisfactory and performance is good, you can then confidently switch it to be the active version.
After deployment, these strategies can help keep everything running reliably:
为运维团队提供运行手册,描述代码中人工智能生成部分的任何特殊方面:“此服务使用人工智能模型处理 X;如果模型输出出现错误,请尝试重启服务或检查模型版本。”或者“功能 Y 大量使用缓存以确保良好性能;如果出现性能问题,请检查缓存命中率。” 简而言之,记录所有可能不明显的运维注意事项。如果人工智能引入了依赖项(例如使用临时文件),请注明,以便运维人员知道要监控磁盘空间等。
Provide runbooks for the ops team that describe any special aspects of the AI-generated parts of the code: “This service uses an AI model for X; if the model output seems erroneous, try restarting service or check the model’s version.” Or “Feature Y heavily uses caching to perform well; if performance issues arise, check the cache hit rate.” Essentially, document any operational considerations that might not be obvious. If AI has introduced a dependency (like using a temp file), note that, so ops will know to monitor disk space and the like.
除了在开发过程中和推广过程中进行测试外,一些公司还会以安全的方式在生产环境中进行测试 (TiP),例如持续进行小型实验。例如,您可以使用功能开关为一小部分用户启用 AI 生成的功能,并观察错误率是否发生变化。这与金丝雀发布有重叠之处,但您可以使用功能开关进行更精细的控制。
In addition to testing during development and as part of the rollout, some companies do testing in production (TiP) in safe ways, like running continuous small experiments. For instance, you might use feature flags to turn on an AI-generated feature for a small subset of users and see if any error rates change. This overlaps with canary releases, but you can make it more granular using feature toggles.
应定期对代码库进行安全性和性能审计,尤其是在人工智能贡献不断增加的情况下。这与管理技术债务类似:它能帮助你发现那些起初看似正常,但随着规模或环境变化可能出现问题的问题。还要注意“漂移”——如果 AI 代码生成 SQL 查询,请确保迁移和代码保持同步,并在新代码开始承载流量之前正确运行迁移。
Schedule periodic security and performance audits of the codebase, especially as more AI contributions accumulate. This is similar to managing tech debt: it helps you catch things that were fine at first but that could turn problematic as the scale or context changes. Watch for “drift,” too—if AI code is generating SQL queries, make sure that your migrations and code stay in sync and that the deployment runs migrations properly before new code takes traffic.
这一主题仍在延续——人应该监控自动化系统。人工智能或许能帮你编写代码,但它无法在凌晨两点修复生产环境中的故障。你需要安排一位了解系统的人员值班。随着时间的推移,你可以利用人工智能进行故障排除,例如分析日志(一些新兴工具具备此功能),但最终,修复方案的决策应该由人来制定。
The theme continues—humans should monitor the automations. AI might help you write code, but it won’t fix a production incident at 2 a.m. Have someone on call who understands the system. Over time, you might enlist AI for troubleshooting help like analyzing logs (a feature of some emerging tools), but at the end of the day, a human should make decisions about fixes.
没有任何流程是百分之百完美的。如果某个错误突破了你的防御体系并导致了事故,请进行事后分析。确定问题是否与人工智能的使用有关(例如“我们信任了这里的人工智能代码,但它在场景 X 下失效了”),并更新你的流程和测试,以防止此类问题再次发生。每次都进行此类分析可以持续提高可靠性。
No process is 100% perfect. If an error gets through your defenses and causes an incident, do a postmortem. Identify if the problem was related to AI usage (like “We trusted the AI code here and it failed under scenario X”), and update your processes and tests to prevent that class of issue. Doing this kind of analysis every time continuously improves reliability.
当然,可靠性不仅仅关乎代码;它还涉及代码的基础设施和运维。人工智能主要在代码层面发挥作用。稳健的运维实践(人工智能可以部分辅助这些实践)确保了整个系统的可靠性。
Reliability isn’t just about code, of course; it also involves the infrastructure and operations around the code. AI helps mostly on the code side. Robust operational practices (which can be partially assisted by AI) keep the overall system reliable.
从本质上讲,在部署方面,对待人工智能密集型项目要像对待任何高质量软件项目一样:进行彻底的测试,逐步推出,严密监控,并确保可以快速回滚。由于人工智能可以更快地创建变更,因此您最终可能需要更频繁地部署(如果您的 CI/CD 流水线运行良好,这当然没问题)。事实上,与不频繁的大规模部署相比,频繁的小规模部署反而能降低风险。原因在于,每次变更都较小,因此更容易识别和修复出现的问题。如果出现问题,回滚小规模变更也更简单快捷。这种方法与大规模、不频繁的发布形成鲜明对比,后者将大量变更捆绑在一起,使得定位问题根源变得困难,并增加了部署失败的潜在影响。
In essence, treat an AI-heavy project the same as any high-quality software project when it comes to deployment: employ thorough testing, roll out gradually, monitor heavily, and make sure you can roll back quickly. Because AI can create changes faster, you may end up deploying more frequently (which is fine, if your CI/CD pipeline is good). Frequent small deployments are actually known to reduce risk compared to infrequent big ones. The reason is that each individual change is smaller, making it easier to identify and fix any issues that arise. If a problem occurs, rolling back a small change is also simpler and faster. This approach contrasts with large, infrequent releases where numerous changes are bundled together, making it difficult to pinpoint the cause of any problems and increasing the potential impact of a failed deployment.
遵循这些最佳实践,即使系统的大部分代码是由机器生成的,您也能确保整个系统为用户提供可靠的服务。自动化测试、谨慎部署和监控的结合,形成了一个完整的闭环,可以及时发现并解决早期阶段遗漏的问题。因此,您既能享受到人工智能开发带来的速度和效率优势,又能确保生产环境中软件的可靠性。
By following these best practices, you can be confident that even though a lot of its code was machine-generated, your system as a whole will behave reliably for users. The combination of automated testing, careful deployment, and monitoring closes the loop to catch anything that slipped through earlier stages. As a result, you can reap the speed and productivity benefits of AI development without sacrificing your ability to trust your software in production.
总而言之,Vibe编码并不能取代工程严谨性——它只是提升了那些运用严谨性的工程师的效率。你应该谨记那句古老的俄罗斯谚语:信任,但要核实。信任人工智能能够处理繁琐的工作,但要用你的工具和专业知识来验证一切。
In summary, vibe coding does not remove the need for engineering rigor—it amplifies the productivity of the engineers who apply that rigor. Your mantra should be the old Russian proverb: Trust but verify. Trust the AI to handle the grunt work, but verify everything with your tools and expertise.
安全性和可靠性是负责任开发的其中一个维度;伦理道德是另一个维度。人工智能辅助编码引发了关于知识产权、偏见、对开发者就业的影响等诸多重要问题。第九章将深入探讨这些更广泛的影响。如何负责任且公平地使用人工智能编码工具?如何处理人工智能生成代码的许可问题,并确保您的模型和提示以符合伦理的方式使用?
Security and reliability are one dimension of responsible development; ethics is another. AI-assisted coding raises important questions about intellectual property, bias, the impact on developer jobs, and more. Chapter 9 will delve into those broader implications. How can you use AI coding tools responsibly and fairly? How do you deal with licensing of AI-generated code and ensure your models and prompts are used ethically?
随着人工智能辅助开发变得越来越普遍,解决这一新范式的伦理和社会影响至关重要。本章将不再深入技术细节,而是从伦理的角度审视氛围编码:这些新的开发方法可能有效,但也需要负责任地实施,以造福个人和社会。
As AI-assisted development becomes increasingly commonplace, it’s critical to address the ethical and societal implications of this new paradigm. This chapter steps back from the technical details to examine vibe coding through an ethical lens: these new development methods can be effective, but they also need to be implemented responsibly and to benefit individuals and society at large.
我首先探讨知识产权(IP)问题。人工智能生成的代码归谁所有?未经授权使用可能源自开源代码的人工智能输出是否合法?接下来,我会考虑偏见和公平性问题。透明度是另一个重点:开发者是否应该披露代码库中哪些部分是由人工智能生成的?团队如何确保代码质量和漏洞的问责制?
I begin with questions of intellectual property (IP). Who owns the code that AI generates, and is it permissible to use AI outputs that may be derived from open source code without attribution? From there, I consider bias and fairness. Transparency is another focus: should developers disclose which parts of a codebase were AI-generated, and how can teams ensure accountability for code quality and bugs?
本章概述了人工智能应用中负责任的开发实践,包括建立透明度和问责制、避免在提示信息中使用敏感数据,以及确保可访问性和包容性。最后,本章提供了一套负责任地使用人工智能工具的指导原则。
I outline responsible development practices in AI usage, from establishing transparency and accountability to avoiding sensitive data in prompts to ensuring accessibility and inclusivity. The chapter finishes with a set of guidelines for using AI tools responsibly.
以下部分涉及本文主要从美国视角探讨复杂的法律议题,特别是版权和知识产权法方面的问题。法律体系和解释在全球范围内不断发展演变,尤其是在人工智能领域。本文信息仅供教育用途,不构成法律建议。在根据本文信息做出任何决定之前,您应咨询合格的知识产权律师,尤其是在您对自身或人工智能工具生成的代码的所有权或许可有任何疑问时。
The following section touches on complex legal topics, particularly concerning copyright and intellectual property law, from a primarily US perspective. Legal systems and interpretations are evolving worldwide, especially concerning artificial intelligence. This information is for educational purposes only and does not constitute legal advice. You should consult with a qualified intellectual property lawyer before making any decisions based on this information, especially if you have concerns about the ownership or licensing of code you or an AI tool generates.
人工智能生成的代码归谁所有?使用这些代码是否尊重人工智能训练所依据的源材料的许可和版权? 像GPT这样的AI模型已经使用来自互联网的大量代码进行训练,其中包括采用各种许可证(MIT、GPL、Apache等)的开源代码库。如果AI生成的代码片段与GPL许可项目中的代码非常相似(或完全相同),那么在专有代码库中使用该代码片段可能会无意中违反GPL协议,因为GPL通常要求共享衍生代码。
Who owns AI-generated code? And does using it respect the licenses and copyrights of the source material on which the AI was trained? AI models like GPT have been trained on huge swaths of code from the internet, including open source repositories with various licenses (MIT, GPL, Apache, etc.). If the AI generates a snippet that is very similar (or identical) to something from a GPL-licensed project, using that snippet in a proprietary codebase could inadvertently violate the GPL, which generally requires sharing derivative code.
根据开源规范和一般版权原则,如果几行代码的小片段缺乏足够的原创性,不足以被视为独立的创作作品,则可能无法获得版权保护;或者,它们的使用可能被视为微不足道(过于琐碎,不值得法律关注)。然而,任何具有实质性或体现独特创意的作品都更有可能受到版权保护。必须明确的是,“开源”并不意味着“公共领域”。默认情况下,包括代码在内的创意作品受其作者的专属版权保护。开源许可证明确授予了原本受版权法限制的权限。
According to open source norms and general copyright principles, small snippets of a few lines might not be copyrightable if they lack sufficient originality to be considered an independent creative work, or their use could potentially be considered de minimis (too trivial to warrant legal concern). However, anything substantial or expressing a unique creative choice is more likely to be protected by copyright. It’s crucial to understand that “open source” does not mean “public domain.” By default, creative work, including code, is under exclusive copyright by its author. Open source licenses explicitly grant permissions that would otherwise be restricted by copyright law.
如果您想了解更多关于开放的信息参考标准,以下是一些不错的起点:
If you want to know more about open source norms, good places to start include the following:
OSI定义并推广开源软件,维护开源定义,并批准符合其标准的许可证。
The OSI defines and promotes open source software, maintains the Open Source Definition, and approves licenses that meet its criteria.
自由软件基金会 ( FSF )倡导“自由软件”(这与开源原则有很强的重叠性),并且是 GNU 通用公共许可证 (GPL) 等许可证的管理者。
The FSF advocates for “free software” (which has a strong overlap with open source principles) and is the steward of licenses like the GNU General Public License (GPL).
单个开源项目通常包含LICENSE文件、README文件和CONTRIBUTING指南,详细说明该特定项目的使用条款和贡献方式。
Individual open source projects typically include LICENSE files, README files, and CONTRIBUTING guidelines that detail the terms of use and contribution for that specific project.
GitHub 等网站提供了关于开源实践的大量文档和讨论。Linux 基金会等组织和法律信息网站也提供了关于开源合规性和法律方面的宝贵资源。
Websites like GitHub offer extensive documentation and discussions on open source practices. Organizations like the Linux Foundation and legal information sites also provide valuable resources on open source compliance and legal aspects.
使用少量代码片段是否符合合理使用原则(在美国称为“合理使用”,在许多其他司法管辖区称为“公平交易”)是一个复杂且高度依赖于具体事实的问题。合理使用原则允许在未经许可的情况下有限度地使用受版权保护的材料,例如用于评论、批评、新闻报道、教学、学术研究或科研等目的。美国法院通常会考虑以下四个因素来判断合理使用:
The question of whether using small code snippets overlaps with the fair use doctrine (in the US; “fair dealing” in many other jurisdictions) is complex and highly fact-dependent. Fair use permits limited use of copyrighted material without permission for purposes such as criticism, comment, news reporting, teaching, scholarship, or research. US courts typically consider four factors to determine fair use:
使用目的和性质(商业用途与非营利用途,变革性用途与复制性用途)
The purpose and character of the use (commercial versus nonprofit, transformative versus duplicative)
受版权保护作品的性质(高度创意性与事实性)
The nature of the copyrighted work (highly creative versus factual)
就受版权保护的作品整体而言,所使用部分的数量和实质性
The amount and substantiality of the portion used in relation to the copyrighted work as a whole
该使用对受版权保护作品的潜在市场或价值的影响
The effect of the use upon the potential market for or value of the copyrighted work
虽然有人可能会认为,为了实现互操作性或获取不受版权保护的创意而复制非常小的功能性代码片段可能属于合理使用范畴,尤其是在这种使用具有转换性的情况下,但这并非代码法律领域的一个明确界定,也没有普遍认可的、界定“合理使用”或“最低限度使用”的代码行数标准。最稳妥的做法通常是获得许可,或者理解其背后的理念,然后以自己的方式重写代码。美国最高法院在“谷歌有限责任公司诉甲骨文美国公司”一案中探讨了软件API领域的合理使用问题,裁定谷歌对Java API声明代码的重新实现属于合理使用。但这是一项针对API声明而非所有代码的具体且复杂的裁决。人们普遍认为,版权保护的是思想的具体表达方式,而非思想本身、程序或操作方法。
While some might argue that copying very small, functional code snippets for interoperability or to access uncopyrightable ideas could fall under fair use, especially if the use is transformative, this is not a clearly settled area of law for code, and there’s no universally agreed-upon number of lines that is definitively “fair use” or de minimis. The safest course is often to get permission or to understand the underlying idea and rewrite the code in your own way. The U.S. Supreme Court case Google LLC v. Oracle America, Inc. addressed fair use in the context of software APIs, finding Google’s reimplementation of Java API declaring code to be fair use, but this was a specific and complex ruling focused on API declarations, not all code. It’s generally understood that copyright protects the specific expression of an idea, not the idea, procedure, or method of operation itself.
通常情况下,使用人工智能的开发者被认为是“作者”,因为人工智能是一种工具,类似于编译器或文字处理器。因此,如果代码是在工作环境中生成的,那么开发者的公司很可能拥有开发者使用该工具生成的代码,但需遵守人工智能工具的服务条款和相关的知识产权问题。然而,人工智能工具的服务条款至关重要。大多数服务条款都授予用户对其生成输出的权限。例如,OpenAI 的服务条款规定:“您拥有使用 GPT-4 创建的输出结果,包括代码。”
Typically, the developer using the AI is considered the “author” in the sense that the AI is a tool, similar to a compiler or a word processor. Thus, if code is generated in a work context, the developer’s company would likely own the code produced by the developer using the tool, subject to the AI tool’s terms of service and underlying IP issues. However, the terms of service (ToS) of AI tools are critical. Most ToS grant the user rights to the output they generate. OpenAI’s ToS, for instance, states, “You own the outputs you create with GPT-4, including code.”
然而,这种“所有权”需要仔细考虑。这通常意味着人工智能提供商不会声称拥有您使用其工具创建的内容的所有权。但这假设您拥有所提供输入内容的权利,并且并不意味着输出本身自动符合版权保护条件,或者不受第三方知识产权主张的影响。如果您将自己的原创代码输入工具进行修改或扩展,则输出很可能属于您(或您的雇主),当然,这取决于人工智能如何处理代码以及它从训练数据中整合了哪些内容。但是,如果您输入他人的受版权保护的代码进行修复或转换,则输出可能被视为该第三方代码的衍生作品。
This “ownership,” however, needs careful consideration. It generally means that the AI provider isn’t claiming ownership of what you create with their tool. But this assumes you have the rights to the inputs you provide, and it doesn’t automatically mean the output is itself eligible for copyright protection or that it’s free from third-party intellectual property claims. If you input your own original code to the tool for modification or extension, the output is most likely yours (or your employer’s), again, subject to how the AI processes it and what it incorporates from its training data. But if you input someone else’s copyrighted code to fix or transform, the output might be considered a derivative work of that third-party code.
在美国和许多其他司法管辖区,人工智能生成的与训练数据实质相似的输出,或基于受版权保护的输入生成的输出,是否构成衍生作品,目前仍存在法律争议,尚未完全明确。切勿将大量并非您所有(或未获得适当许可)的受版权保护的代码输入人工智能工具,因为其输出可能被视为衍生作品,从而受原始受版权保护代码的许可约束。
In the US and many other jurisdictions, whether AI-generated output that is substantially similar to training data, or output based on copyrighted input, constitutes a derivative work is a subject of ongoing legal debate and lacks full clarity. Don’t feed large chunks of copyrighted code that isn’t yours (or licensed appropriately) into an AI tool, because the output could be deemed a derivative work and thus fall under the license of that original copyrighted code.
鉴于这些不确定性,为安全起见,应将人工智能生成的代码视为受模糊许可协议约束,仅在确信其不侵犯现有版权且能够遵守任何潜在的开源许可义务的情况下才使用。关于人工智能输出本身的版权状态,美国版权局已声明,完全由人工智能生成且缺乏充分人类参与的作品不享有版权。如果人类对人工智能输出进行重大修改或编排,则该作品可能享有版权 。人工智能以创造性的方式生成素材,其中人类的贡献可能享有版权,但人工智能生成的元素本身则不享有版权。因此,通常明智的做法是假设纯粹由人工智能生成的输出可能不受任何人的版权保护,或者版权仅限于人类的创造性贡献。
Given these uncertainties, to be safe, treat AI-generated code as if it’s under an ambiguous license, and only use it if you are comfortable that it doesn’t infringe on existing copyrights and that you can comply with any potential open source license obligations. Regarding the copyright status of the AI output itself, the US Copyright Office has stated that works generated solely by AI without sufficient human authorship are not copyrightable. If a human significantly modifies or arranges AI-generated material in a creative way, that human contribution might be copyrightable but not the AI-generated elements standing alone. Thus, it’s often wise to assume that purely AI-generated outputs might not be copyrightable by anyone or that copyright would extend only to the human’s creative contributions.
这并非杞人忧天。事实上,这方面目前存在法律争议。一起著名的集体诉讼案,即 Doe 诉 GitHub, Inc.,针对 GitHub、微软和 OpenAI 提起,声称 GitHub Copilot 生成的代码与已获许可的开源代码过于相似,且没有进行适当的署名或遵守许可条款。 虽然本案中的一些诉讼请求已被驳回或正在上诉中(截至2025年中期,该案仍在进行中,包括就《数字千年版权法案》(DMCA)索赔和剩余的违约索赔向第九巡回上诉法院提起上诉),但它凸显了一个真正的担忧:人工智能可以而且有时确实会从其训练数据中直接复制或近似改写受版权保护的代码。
This is not a hypothetical worry. In fact, there’s ongoing legal debate. A prominent class-action lawsuit, Doe v. GitHub, Inc., was filed against GitHub, Microsoft, and OpenAI, claiming that GitHub Copilot produces code that is too similar to licensed open source code without proper attribution or adherence to license terms. While some claims in this case have been dismissed or are under appeal (as of mid-2025, the case involves ongoing proceedings, including an appeal to the Ninth Circuit regarding DMCA claims and remaining breach of contract claims), it highlights a genuine concern: AI can and sometimes does regurgitate or closely paraphrase copyrighted code from its training data.1
GitHub 自身一项较早(但仍然相关且后来得到证实)的研究指出,在某些情况下,Copilot 的输出包含与训练数据相匹配的建议,甚至包括极少数较长的逐字片段。虽然大多数人工智能工具的设计都旨在避免直接、大范围地复制可识别的代码,除非有明确提示或处理的是非常标准的算法,但这种风险依然存在。此外,令人担忧的不仅仅是开源代码;许多作家、艺术家和媒体公司提起诉讼,指控其完全受版权保护的私有知识产权未经许可或补偿被用于训练大型语言模型和其他生成式人工智能系统。专有代码的挑战在于,与开源代码不同,它通常不公开可见,这使得最终用户更难确认人工智能的输出是否无意中与此类私有代码相似。
An older (but still relevant and later substantiated) study by GitHub itself noted that, in some cases, Copilot’s output included suggestions that matched training data, including rare instances of longer verbatim snippets. While most AI tools are designed to avoid direct, extensive copying of identifiable code unless specifically prompted or dealing with very standard algorithms, the risk exists. Furthermore, it’s not just open source code that’s a concern; numerous lawsuits have been filed by authors, artists, and media companies alleging that their fully copyrighted, privately owned intellectual property was used without permission or compensation to train large language models and other generative AI systems. The challenge with proprietary code is that, unlike open source, it’s often not publicly visible, making it harder for an end user to confirm if an AI’s output is inadvertently similar to such private code.
然而,合乎道德且谨慎的做法是,将您从人工智能工具中接受的任何代码都视为您自己的责任。在将任何人工智能生成的代码集成到您的项目中之前,请务必彻底审查、测试并理解这些代码,并确保其使用符合所有适用的许可和版权法。
Nevertheless, the ethical and prudent practice is to act as if any code you accept from an AI tool is your responsibility. Thoroughly review, test, and understand any AI-generated code before incorporating it into your projects, and ensure its use complies with all applicable licenses and copyright laws.
如果人工智能的输出看起来像是已知代码的逐字或近乎逐字的复制品(尤其是如果它包含独特的注释或作者姓名),请谨慎对待。考虑使用抄袭检测工具进行相似性检查,或者在网上搜索独特的字符串,看看是否能找到任何可能表明抄袭的匹配项。
If an AI output seems like a verbatim or near-verbatim copy of known code (especially if it includes distinctive comments or author names), treat it carefully. Consider running a similarity check using a plagiarism detector tool, or do a web search for unique strings to see if you find any matches that could indicate copying.
另一个需要遵循的原则是:如有疑问,请勿使用。要么避免使用输出结果,要么确保其采用兼容的许可协议,并在需要时注明出处。例如,如果 Copilot 输出的算法实现是你在 Stack Overflow 或开源项目中看到的,请注明出处或以你自己的方式重写,以 AI 的答案为参考,但不要逐字引用。
Another principle to follow is When in doubt, leave it out. Either avoid using the output or make sure it’s under a compatible license and give attribution if required. For example, if Copilot spits out a well-known algorithm implementation that you recognize from Stack Overflow or an open source project, cite the source or rewrite it in your own way, using the AI’s answer as a guide but not quoting it verbatim.
如果您怀疑输出结果与现有库的解决方案匹配,请考虑直接引入该库(并确保拥有相应的许可证)。您也可以向 AI 发出以下提示:
If you suspect the output matches an existing library solution, consider including the library itself instead (with proper license). You can also prompt the AI:
请提供原创实现,而不是从库中复制的代码。
Please provide an original implementation rather than one copied from a library.
这样它或许能综合出一个更独特的解决方案。(虽然不能保证它不会受到训练代码的影响,但至少它会尽量避免直接抄袭。)
It might then synthesize a more unique solution. (There’s no guarantee it won’t be influenced by its training code, but at least it will try to not copy outright).
这里涉及的伦理问题还包括不得利用人工智能故意剥夺署名权。例如,通过人工智能从 Stack Overflow 复制代码而不注明出处,以此规避必须注明答案来源的政策,这是不道德的。这会削弱人们对开放知识生态系统的信任。更好的做法是正确引用资料并注明出处。根据具体情况,这可能意味着以下几点:
The ethics here also touch on not using AI to willfully strip attribution. For example, it would be unethical to copy code from Stack Overflow via AI without attribution to circumvent a policy that you should credit the answer. That erodes trust in the open knowledge ecosystem. It’s better to incorporate the material with proper credit. Depending on the circumstances, that might mean the following:
如果人工智能从某个来源(例如复制一段带有“John Doe 2018”字样的代码片段)生成代码注释,你应该保留该注释,或者将其移至包含完整引用的正确署名部分,而不是删除它。这样做是对原作者的尊重。
If an AI writes a code comment from some source that has an author’s name (like copying a snippet with “John Doe 2018” in a comment), you should keep that or move it to a proper attribution section with a full citation rather than deleting it. That respects the original author’s credit.
如果人工智能提供的解决方案你知道源自某个已知的算法或代码片段,请像你自己查找该算法或代码片段一样,引用该来源。
If an AI provided a solution that you know comes from a known algorithm or code snippet, cite that source as you normally would if you had looked it up yourself.
如果人工智能工具创造出了具有一定创造性的内容(例如独特的方法或文档文本),请承认其贡献。虽然它不拥有权利,但这关乎透明度(或许也应该对这项技术表示认可)。
If an AI tool creates something arguably creative (like a unique approach or text for documentation), acknowledge its contribution. Though it doesn’t have rights, it’s about transparency (and maybe a nod to the tech).
有些开源许可证(例如 MIT)比较宽松,只要注明出处,复制的代码就可以使用。而另一些许可证,例如 GPL 或 AGPL,则规定如果使用其中的代码,就会“感染”你的整个代码库,这对于封闭项目来说是不可取的。
Some open source licenses (like MIT) are permissive enough that including copied code with attribution would satisfy the license. Others, like GPL or AGPL, would “infect” your whole codebase if you include that code, which is undesirable for closed projects.
简而言之:如果您怀疑人工智能给您提供了可能造成知识产权问题的内容,请避免使用它,或者对其进行充分的转换,以确保您遵守任何可能的许可。
In short: if you suspect the AI has given you something that might cause IP issues, either avoid using it or transform it sufficiently to ensure you’re complying with any possible license.
即使在我撰写本文时,人工智能工具仍在不断引发关于知识产权、版权和伦理的新问题。例如:
Even as I write this, AI tools continue to raise new questions about IP, copyright, and ethics. For instance:
如果你的创意编码包括使用人工智能生成非代码资源,例如文档文本、配置文件或图像,那么就会出现类似的知识产权问题。例如,如果你使用基于受版权保护图像训练的人工智能工具生成图标图像,那么这张新图像的所有权归谁?
If your vibe coding includes using AI to generate noncode assets like documentation text, config files, or images, similar IP questions arise. For instance, if you generate an icon image via an AI tool that was trained on copyrighted images, who owns that new image?
如果人工智能编写了软件产品的重要部分,那么训练人工智能所用代码的原始作者是否应该获得荣誉?
If an AI writes a significant part of a software product, should the original authors of the code on which the AI was trained get credit?
是否有人会因为你的AI生成代码与他们的代码相似而声称其侵犯了他们的版权?如果代码中相当一部分长度相同的代码片段可能完全相同,那么相似性检测就派上用场了。
Could someone claim that your AI-generated code infringes on their copyright because it looks similar to theirs? If sections of nontrivial lengths are possibly identical, this is where similarity checking comes in.
一种新兴观点认为,人工智能公司可能需要实施尊重许可协议的过滤机制,或者允许团队选择不将其代码纳入人工智能训练数据。这种观点仍在发展演变中,但一线开发人员应谨慎行事,避免侵犯他人权利。
There’s an emerging notion that AI companies might need to implement license-respecting filters or allow teams to opt out of their code being included in AI training data. It’s evolving, but developers on the ground should act conservatively to not violate rights.
法院需要时间来解决所有法律问题,但在此期间,我们应该秉持学术诚信和尊重原则。如果人工智能使用了已发表论文中的已知算法,请在评论中引用该论文。如果它使用了常见的开源辅助代码,请注明项目出处。这体现了对作者的尊重。如果您知道某项成果的来源,请务必注明出处。这是一种有助于提高透明度的良好做法。
It will take time for courts to settle all of the legal issues, but in the meantime, intellectual honesty and respect should guide us. If AI uses a known algorithm from a published paper, cite the paper in a comment. If it uses a common open source helper code, credit the project. It’s about respect for authorship. If you recognize where something came from, err on the side of giving credit. It’s a good practice that fosters transparency.
请记住,人工智能的知识源自成千上万公开分享代码的开发者。从伦理角度来看,软件行业有义务尊重这个社区,遵守开源许可和规范。请注明出处。这是到期的事,不要滥用他人的劳动成果。伪装成“这是人工智能写的,不是我写的”。
Remember that under the hood, the AI’s knowledge comes from thousands of developers who shared their code publicly. Ethically, the software industry owes that community the respect of upholding open source licenses and norms. Give credit where it’s due and don’t abuse others’ work under the guise of “the AI wrote it, not me.”
透明度是指公开说明在开发过程和输出中使用人工智能的情况,而归属感是指当人工智能衍生代码来自可识别的来源时,给予适当的署名。
Transparency refers to being open about the use of AI in your development process and outputs, and attribution refers to giving proper credit when AI-derived code comes from identifiable sources.
为了确保问责,透明度至关重要。例如,如果人工智能生成的代码引入了漏洞或安全缺陷,明确说明“这段代码是人工智能建议的”可能有助于分析根本原因——或许应该重写含糊不清的提示。在代码注释、项目 README 或文档中,您可以概括地提及“本项目是在 ChatGPT 等人工智能工具的辅助下构建的”。或者更具体地说明:“添加了一个解析 CSV 文件的函数(CSV 文件由 ChatGPT 生成,然后进行了修改)。”这有点像承认您使用了框架或库。
Transparency is important for the sake of accountability. For example, if AI-generated code introduces a bug or security flaw, being transparent that “this code was AI-suggested” might help you analyze the root cause—perhaps an ambiguous prompt should be rewritten. In code comments or a project’s README or documentation, you might mention generally that “this project was built with assistance from AI tools like ChatGPT.” Or get more specific: “Added a function to parse CSV (generated with ChatGPT’s help, then modified).” It’s a bit like acknowledging your use of frameworks or libraries.
透明度也是建立信任的关键:利益相关者(您的团队、客户、最终用户或行业监管机构)可能想了解您的软件是如何开发和验证的。如果代码生成过程中使用了人工智能,一些利益相关者可能会错误地对其信任度过高或过低。透明度使得关于可靠性的讨论成为可能:“是的,我们使用了人工智能,但我们对其进行了彻底的测试”或“这部分比较棘手——我们最初使用人工智能生成了代码,但之后我们对其进行了验证。”
Transparency is also key to trust: stakeholders (your team, clients, end users, or industry regulators) might want to know how your software was developed and validated. If an AI was involved in code generation, some stakeholders might wrongly trust it too much or too little. Transparency allows a conversation about reliability: “Yes, we used AI, but we tested it thoroughly” or “This part was tricky—we had AI generate the initial code, but we’ve since verified it.”
许多学术场合也要求或期望注明出处。一些开源项目出于知识产权方面的考虑,限制甚至禁止人工智能贡献代码,因此在使用人工智能之前,请务必查看贡献者指南。如果某个补丁是由人工智能生成的,请向维护者公开说明,这有助于他们进行评估,尤其是在担心许可问题的情况下。
Attributions are also expected or required in many academic venues. Some open source projects restrict or even forbid AI contributions due to IP concerns, so check the contributor guidelines before using AI. Being transparent with maintainers if a patch was AI-generated helps them evaluate it, especially if licensing is a worry.
事实上,一些监管严格的行业要求软件供应商披露任何人工智能的使用情况,以备审计之用。欧盟的《人工智能法案》也强制要求透明度。对于影响个人的自动化决策(例如信用评分算法),如果“氛围编码”最终应用于此类系统,那么告知用户“推荐内容为自动生成,可能反映数据中的模式”就成为一项法律/道德上的必要要求。
In fact, some highly regulated industries require software vendors to disclose any AI use for auditing purposes. The EU’s AI Act mandates transparency for automated decision making that affects individuals (such as credit-scoring algorithms). If vibe coding leads to such systems, it becomes a legal/ethical necessity to inform users that “recommendations are generated automatically and may reflect patterns in data.”
同样,如果您的产品会将用户数据或专有数据(例如用户提供的代码示例)输入到人工智能模型中,以优化模型并帮助其进行分析,那么您可能需要在隐私政策中说明,用户数据可能会在获得许可的情况下用于改进人工智能模型(一如既往,请就法律问题咨询律师)。透明度与隐私在此交织在一起。
Similarly, if your product feeds user data or proprietary data like user-provided code examples into an AI model to fine-tune it and help program its analysis, you might need to say in the privacy policy that user data may be used with permission to improve AI models (as always, do consult a lawyer for legal matters). Transparency intersects with privacy here.
此外,注明所使用的工具和资源也是一种基本的道德规范。如果你的代码中有 30% 是由 Copilot 生成的,那么在你的文档或内部沟通中提及这一点是合理的——这并非为了贬低你自己的作用,而是为了对整个过程保持诚实。
It’s also just generally ethical to acknowledge the tools and sources you use. If 30% of your code was generated by Copilot, it’s fair to mention that in your documentation or internal communication—not to diminish your own role but to be honest about the process.
有些开发者可能害怕承认人工智能的帮助,担心这会削弱他们对自身贡献或技能的认可,或者被视为“作弊”。随着直觉式编程(vibe coding)的普及,这种偏见应该会逐渐减少;最终,如果你不使用现有的人工智能,反而可能会被认为落伍。我们需要将人工智能视为一种工具——它并不比使用 Stack Overflow 或集成开发环境(IDE)更“作弊”。
Some developers might fear admitting that AI helped, worried that it could undermine their perceived contribution or skill or be seen as “cheating.” As vibe coding becomes more normalized, this stigma should decrease; eventually, you might be seen as behind the times if you’re not using the AI available to you. We need to normalize AI as a tool—it’s no more “cheating” than using Stack Overflow or an IDE.
另一方面,免责声明过多可能会引起不必要的担忧。如果你告诉客户“我们使用人工智能编写了这个产品”,他们可能会质疑其安全性(即使这种质疑源于误解)。措辞至关重要。同时强调质量措施:“我们利用先进的编码辅助工具来加快开发速度,所有人工智能生成的代码都经过严格的审查和测试,以符合我们的质量标准。”
On the flip side, providing too many disclaimers could cause undue worry. If you tell a client, “We used AI to code this product,” they might question its safety (even if that’s due to misconceptions). It’s important how you phrase it. Emphasize quality measures in the same breath: “We utilized advanced coding assistants to speed up development, and all AI-generated code was rigorously reviewed and tested to meet our quality standards.”
总之,透明度和归属感有助于建立信任和社区价值观。它们确保功劳归于人类创造者,并让我们对软件的构建方式保持诚实。这就像艺术家列出他们的工具或灵感来源一样;这不会贬低艺术,反而能赋予艺术更丰富的内涵。如果你也像我一样,希望“氛围编码”(vibe coding)被广泛接受,那么公开透明地使用人工智能以及如何降低其风险就至关重要。
In sum, transparency and attribution foster trust and community values. They ensure that credit flows to human creators and that we remain honest about how our software is built. It’s akin to an artist listing their tools or inspirations; it doesn’t diminish the art; it contextualizes it. If, like me, you want vibe coding to be accepted widely, being open about using AI and how you mitigate its risks is important.
正如你读到这里所了解到的,人工智能模型的输出反映了它们用来训练的数据。如果数据中存在偏差或排斥性模式,模型可能会产生有偏差或不公平的输出结果。
As you know well by this point in the book, AI models’ output reflects the data they’re trained on. If that data contains biases or exclusionary patterns, the models can produce outputs that are biased or unfair.
你可能会问:“代码怎么会有偏见呢?又不是法学硕士在做招聘决定。” 但偏见确实会以微妙的方式悄悄渗入你的代码中:
You might ask: “How can code be biased? It’s not like an LLM is making hiring decisions or something.” But bias can creep into your coding in subtle ways:
代码通常反映了编写者的假设。人工智能生成的面向用户的文本或内容可能反映了其训练数据中存在的文化偏见或不敏感语言。例如,微软的聊天机器人 Tay 在 2016 年推出后,臭名昭著地在几个小时内就学会了从 Twitter 互动中鹦鹉学舌般地重复种族主义和厌女的侮辱性言论。
Code often reflects assumptions on its creators’ part. User-facing text or content the AI generates might reflect cultural biases or insensitive language present in its training data. For instance, Microsoft’s Tay, an early chatbot in 2016, infamously learned to parrot racist and misogynistic slurs from Twitter interactions within hours of launch.
假设也可能基于特定的文化规范,例如北美中产阶级的生活方式(例如假设拥有汽车或普遍享有某些技术)。一个显著的例子是,未经审视的假设导致了排他性的产品:苹果公司2014年首次发布的“健康”应用缺少经期追踪功能——这一重大疏忽很可能源于设计团队缺乏多样性和视角。即使在示例代码、注释或合成数据中,模型也可能始终使用“他/他”代词,从而强化性别偏见。
Assumptions can also be geared toward specific cultural norms, like a middle-class North American lifestyle (such as assuming car ownership or universal access to certain technologies). A notable example of unexamined assumptions leading to exclusionary products was the initial 2014 release of Apple’s Health app, which lacked a period tracker—a significant oversight likely stemming from a lack of diversity and perspective on the design team. Even in example code, comments, or synthetic data, the model might always use he/him pronouns, reinforcing gender bias.
众所周知,代码库和更广泛的软件开发领域主要反映的是西方视角和英语使用者。因此,人工智能训练这些代码库可能会忽略一些关键的国际化方面,例如对 Unicode 和多字节字符的正确支持(这对中文、日语、韩语、阿拉伯语、印地语以及许多其他使用非拉丁字母或音节文字的语言至关重要),或者可能默认使用以英语为中心的示例来定义类型名称等内容。即使人工智能不会自动进行国际化,开发者也必须提高国际化意识,并在设计和编码过程中考虑国际化。
It is well known that code repositories and the broader software development landscape predominantly reflect Western perspectives and English speakers. As a result, an AI trained on these repositories might overlook crucial internationalization aspects, such as proper support for Unicode and multibyte characters (essential for languages like Chinese, Japanese, Korean, Arabic, Hindi, and many others using non-Latin or syllabary scripts), or it might default to English-centric examples for things like type names. Developers must bring awareness and design and code for internationalization, even if the AI doesn’t spontaneously do so.
编写算法时要谨慎。对于种族、性别、年龄等某些变量,人工智能可能不会主动纳入这些变量,除非被要求这样做。但如果它凭空想象出某些标准,或者如果你在数据集上使用像代码助手这样的人工智能,则需要应用公平性约束;人工智能本身并不了解道德或法律背景。
If writing algorithms, be wary of certain variables like race, gender, age, etc. The AI might not spontaneously include them unless asked, but if it hallucinates some criteria or if you’re using an AI like Code Assistant on a dataset, apply fairness constraints; the AI won’t inherently know the moral or legal context.
除了编码之外,模型还可以反映其内容领域的数据偏差:即其训练数据中存在的历史偏差。例如,假设一个人工智能的任务是编写用于贷款审批的信用评分算法的代码。在美国,信用评分系统长期以来一直反映并延续着种族偏见,这一点已有大量文献记载。这些偏见源于历史上的歧视性做法,例如“红线区”政策和其他形式的系统性歧视,这些做法造成了持久的经济影响,尤其对黑人社区和其他边缘群体而言更是如此。(关于政府政策如何导致美国种族隔离的全面历史,请参阅理查德·罗斯坦的《法律的颜色》(经济政策研究所,2017 年)。)
Beyond just coding, models can mirror data bias in their content domain: the historical biases present in their training data. For example, consider an AI tasked with writing code for a credit-scoring algorithm for loan approvals. In the United States, credit scoring systems have a documented history of reflecting and perpetuating racial biases. These biases stem from historical practices like redlining and other forms of systemic discrimination that have had lasting financial repercussions, particularly for Black communities and other marginalized groups. (See Richard Rothstein’s The Color of Law [Economic Policy Institute, 2017] for a comprehensive history of how government policies segregated America.)
如果训练数据反映了这些历史偏见,人工智能可能会纳入歧视性变量,例如使用邮政编码(由于住房隔离模式,邮政编码可能成为种族人口统计数据的替代指标)或其他看似中立但与受保护特征相关的数据点。如果缺乏适当的引导,人工智能可能会生成导致银行做出不公平贷款决策的代码,从而使历史不平等现象持续存在,并影响人们的日常生活。类似的问题也出现在预测性警务算法等领域,历史逮捕数据(本身可能存在偏见)可能导致人工智能系统不成比例地针对某些特定群体。
If the training data reflects these historical biases, the AI might incorporate discriminatory variables, such as using zip codes (which can be a proxy for racial demographics due to segregated housing patterns) or other seemingly neutral data points that correlate with protected characteristics. If not properly guided, the AI might produce code that leads banks to make unfair lending decisions, thus perpetuating historical inequalities and affecting real people’s lives. Similar issues arise in areas like predictive policing algorithms, where historical arrest data (itself potentially biased) can lead to AI systems that disproportionately target certain communities.
同样地,如果您使用专门的模型(例如,针对医疗软件进行微调的 AI 代码助手),请确保该模型不会受到该领域数据的偏见影响。例如,历史上一些医疗指南受到以男性为主要研究对象的科研结果的影响,导致对其他性别患者造成误诊或治疗效果不佳。如果人工智能要推荐用于医疗诊断的代码或解决方案,则需要仔细检查它是否无意中将这些偏见编码进去。
Similarly, if you’re using specialized models (like an AI code assistant fine-tuned for, say, medical software), ensure the model isn’t locked into biases from that domain’s data. For example, historically, some medical guidelines were biased by research studies that predominantly used male subjects, leading to misdiagnoses or less effective treatments for other genders. If AI is recommending code or solutions for medical diagnostics, you need to double-check that it doesn’t inadvertently encode those biases.
虽然目前已经出现了一些用于检测人工智能输出中偏见的工具,但这些工具在用于生成内容的GPT模型中更为常见,而且人工智能提供商本身也会尝试过滤掉明显带有偏见或有害的输出。面向代码的人工智能很少会自发地生成仇恨言论,但它们配备内容过滤器来过滤仇恨言论是件好事。在许多人工智能工具中,内置的伦理约束意味着,如果用户试图让人工智能创建恶意软件或歧视性算法,它会拒绝。不要试图绕过这些过滤器来获取不道德的输出。
There are tools emerging to detect bias in AI outputs, though these are more common in GPT models used to generate content, and AI providers themselves attempt to filter overtly biased or toxic outputs. Code-oriented AIs rarely produce hate speech spontaneously, but it’s good that they have content filters for it. Building in ethical constraints means, in many AI tools, that if a user tries to get the AI to create malware or discriminatory algorithms, it will refuse. Don’t try to break those filters to get unethical outputs.
不过,在开发过程的不同阶段,还有许多其他方法可以识别和减轻偏见。这些方法包括:
There are lots of other ways to recognize and mitigate bias at different stages of the development process, though. These include:
如果你的 AI 生成面向用户的组件或处理与人类相关的数据的逻辑,请使用各种输入对其进行测试。例如,如果人工智能生成的表单验证需要“名字”和“姓氏”,它是否允许使用在某些文化中很常见的单名?如果不允许,那就是假设上的偏差。如果它生成示例用户名,这些用户名是否都像“JohnDoe”一样?如果是这样,请考虑在示例中增加更多多样性。
If your AI generates user-facing components or logic that deals with human-related data, test it with diverse inputs. For example, if an AI-generated form validation expects “First Name” and “Last Name,” does it allow single names, which are common in some cultures? If not, that’s a bias in assumption. If it generates sample usernames, are they all like “JohnDoe”? If so, consider incorporating more diversity in the examples.
您可以明确地指示人工智能应保持中立或包容:“请使用来自不同文化的各种名称生成示例。” 如果它总是将用户称为“他”,您可以提示:
You can explicitly instruct the AI to be neutral or inclusive: “Generate examples using a variety of names from different cultures.” If it always refers to the user as “he,” you might prompt:
代码注释中请避免使用性别化的语言;请使用中性措辞或使用他们/她们的代词。
Avoid gendered language in this code comment; use neutral phrasing or they/them pronouns.
此外,要谨慎对待人工智能可能生成的、带有文化敏感性的笑话或例子;您可以提示它使用专业的语气来避免这种情况。人工智能通常会照做。它没有预设的意图;除非另有指示,否则它只会输出它认为正常的内容。而我们塑造了这种“正常”。
Also, be cautious about jokes or examples the AI might produce that could be culturally insensitive; you can prompt it to use a professional tone to avoid that. The AI will usually comply. It doesn’t have an agenda; it just outputs what seems normal to it, unless told otherwise. We shape that “normal.”
由不同背景的团队成员进行评审可以发现问题。例如,有人可能会说:“我们的人工智能总是选择像 foo/bar 这样的变量名,这没问题,但在文档中,它的所有角色都是男性化的。” 然后你可以系统地纠正这个问题。如果所有开发人员的背景都相似,他们可能不会注意到这种微妙的偏见。如果可能,在审查人工智能使用指南时,应让来自弱势群体的人员参与进来——或者至少考虑他们的观点。
Having a diverse team review outputs can catch issues. For example, someone might say, “Hey, our AI always picks variable names like foo/bar, which is fine, but in documentation, all of its personas are male-typed.” Then you can correct that systematically. If all developers are from similar backgrounds, they might not catch a subtle bias. If possible, involve people from underrepresented groups—or at least consider their perspectives—when reviewing AI usage guidelines.
总而言之,偏见和公平性指的是利用代码感知工具编写出对所有背景用户都公平的代码,并且这些代码不会反映——更不会延续——历史上存在的歧视。我们在团队中使用这些工具的方式也应该对不同级别和背景的开发人员及其他同事公平。关于人工智能工具如何改变工作场所(尤其是对初级开发人员而言)所带来的伦理影响,请参阅第四章。
In summary, bias and fairness are about using vibe-coding tools to produce code that is fair to users of all backgrounds and that doesn’t reflect—or, worse, perpetuate—historical discrimination. The way we use these tools in teams should also be fair to developers and other colleagues of varying levels and backgrounds. See Chapter 4 for a discussion of the ethical implications of how AI tools are changing workplaces, especially for junior developers.
带来一起很多什么我们已经讨论过了,这是值得的。阐明一套负责任的氛围编码实践:
Bringing together a lot of what we’ve covered, it’s worth articulating a set of responsible practices for vibe coding:
再次强调:永远不要让AI在无人监督的情况下运行。负责任的AI辅助开发意味着开发者需要审查每一行代码并做出决策,而不是未经人工验证就部署AI的原始输出。
Always keep a human in the loop.
Again: never let the AI work unsupervised. Responsible AI-assisted dev means you, the developer, are reviewing every line and making decisions, not deploying raw AI output without human validation.
对你的代码负责。
如果出了问题,那不是人工智能的错,而是开发团队的责任。保持这种心态可以避免自满。无论代码是你自己从零开始编写的,还是从现有的人工智能代码中获取的,你都要做好解释的准备。如果有人问你:“为什么代码会这样做?”不要说:“我不知道,这是Copilot(人工智能助手)做的。” 这就是为什么第三章的黄金法则之一是“永远不要提交你完全不理解的代码”。这才是负责任的工程实践。
Take responsibility for your code.
If something goes wrong, it’s not the AI’s fault—it’s the development team’s responsibility. Keeping that mindset avoids complacency. Be prepared to justify your code, whether you wrote it from scratch or accepted AI code. If someone asks you, “Why does the code do this?” don’t say, “I don’t know; Copilot did that.” That’s why one of Chapter 3’s golden rules is “Never commit code you don’t fully understand.” That’s responsible engineering.
保护用户隐私并征得其同意。
从道德上讲,你有责任这样做。向用户和公司承诺保护他们的机密数据。在使用人工智能工具(尤其是云端工具)时,务必小心,不要在提示或对话中泄露敏感数据。例如,如果您正在调试用户数据库问题,请不要将真实的用户记录提供给 ChatGPT,而应使用经过脱敏处理或合成的数据。
现在很多工具都允许用户(或者至少是企业用户)选择不让他们的输入数据用于训练。如果您是企业用户,请使用这些设置,或者对敏感代码使用本地部署解决方案。如果您确实将任何用户数据提供给模型,或者任何 AI 功能直接接触用户(例如,您应用中使用 LLM 的聊天机器人),请务必征得用户同意,并允许他们在适当情况下选择退出。类似“此功能使用 AI 服务;您的输入将被发送给该服务进行处理”的警告信息清晰透明,让注重隐私的用户自行决定。
Protect users’ privacy and ask for their consent.
Ethically, you owe it to users and your company to keep their secret data secret. When using AI tools, especially cloud-based ones, be careful not to expose sensitive data in your prompts or conversations. For instance, if you’re debugging an issue with a user database, don’t feed actual user records to ChatGPT. Use sanitized or synthetic data instead.
Many tools now allow users (or at least business users) to opt out of having their input data used for training. If you’re an enterprise user, use those settings or use on-prem solutions for sensitive code. If you do feed any user data to a model, or if any AI functionality directly touches users (like a chatbot in your app that uses an LLM), get users’ consent and allow them to opt out if appropriate. A warning like “This feature uses an AI service; your input will be sent to it for processing” is transparent and lets privacy-conscious users decide for themselves.
遵守法律法规。
密切关注人工智能方面的法律要求,数据保护法等法律法规都在不断发展变化。例如,欧盟的《通用数据保护条例》(GDPR) 和《人工智能法案》将某些人工智能输出视为个人数据,只要这些输出包含任何个人数据。使用用户数据训练模型可能需要获得用户的同意。监管机构可能会将代码生成归类为“通用人工智能”,并施加透明度或风险管理义务。请密切关注相关信息,并与您的法律和合规专业人员紧密合作,以避免违反任何法规。
这一点无需赘言,但切勿使用人工智能生成恶意软件、在没有道德理由的情况下利用代码漏洞,或自动化不道德或非法行为。2虽然人工智能或许能够编写非常有效的钓鱼邮件或代码注入攻击,但将其用于此目的违反了伦理道德、大多数国家的法律,而且很可能也违反了人工智能的服务条款。请专注于建设性使用。
Comply with laws and regulations.
Keep an eye on legal requirements around AI, which are constantly evolving. For instance, data protection laws like the EU’s General Data Protection Regulation (GDPR) and AI Act consider some AI outputs as personal data if they include any personal data. Training a model on users’ data might require those users’ consent. Regulatory bodies may classify code generation as “general AI” and impose transparency or risk management obligations. Stay informed and work closely with your legal and compliance professionals to avoid breaking any regulations.
While this should go without saying, do not use AI to generate malware, exploit code without ethical justification, or automate unethical or illegal practices.2 While an AI could probably write a very effective phishing email or code injection attack, using it for that purpose violates ethics, the laws of most countries, and likely the AI’s terms of service. Focus on constructive use.
在您的组织中培养负责任的人工智能文化。
如果你的团队采用氛围编码,请鼓励讨论伦理问题并提供相关的伦理培训。可以考虑让开发人员和代码审查人员使用类似图 9-1所示的简短清单。
每个人都应该对合乎伦理地使用人工智能负有责任;这需要集体的努力,而不仅仅是某个特定时刻使用该工具的个人的责任。为了正式落实这一点,可以考虑在团队或组织内指定一位“伦理负责人”或成立一个小型伦理委员会。这个人或这个小组并非伦理的唯一承担者(因为伦理责任仍然是共同的),但他们将主导以下方面:
密切关注人工智能伦理的最新发展、新兴最佳实践和新的监管环境
促进对特定项目中伦理考量的讨论
倡导将伦理原则融入开发生命周期
协助整理和分发相关资源和培训材料给更广泛的团队
作为团队成员在遇到伦理问题或疑虑时的联络人。
由于该领域发展速度非常快,因此团队合作至关重要,以便及时了解人工智能工具的新版本及其功能、局限性以及负责任使用的不断发展的最佳实践。
由于该领域发展迅速,需要团队协作,及时了解人工智能工具的最新版本和最佳实践。在工作流程中融入一个重要的概念是使用模型卡。模型卡本质上是标准化的文档,它能清晰地展示机器学习模型的相关信息。你可以把它想象成人工智能模型的营养标签。模型卡通常包含以下详细信息:
该模型是什么,它的版本是什么,以及它是什么时候开发的
该模型是针对特定用例设计和测试的。
由于存在局限性或潜在危害,某些情况下不应使用该模型。
该模型在各项基准测试中的表现如何,包括对不同人口统计群体公平性和偏见性的评估。
用于训练模型的数据集信息,包括数据中任何已知的局限性或偏差。
潜在风险和社会影响以及采取的任何缓解策略
Foster a responsible AI culture in your organization.
If your team adopts vibe coding, encourage discussions about ethics and provide relevant ethics training. Consider having developers and code reviewers use a brief checklist like the one in Figure 9-1.
Everyone should feel responsible for ethical AI use; it’s a collective effort, not just the burden of the individual using the tool at any given moment. To formalize this, consider designating an “ethics champion” or a small ethics committee within your team or organization. This individual or group wouldn’t be the sole owner of ethics (as that responsibility remains shared), but they would take the lead on:
Staying abreast of the latest developments in AI ethics, emerging best practices, and new regulatory landscapes
Facilitating discussions about ethical considerations in specific projects
Championing the integration of ethical principles into the development lifecycle
Helping to curate and disseminate relevant resources and training materials to the broader team
Acting as a point of contact for team members who have ethical questions or concerns
Since this field is moving incredibly fast, it’s crucial to work as a team to stay updated on new versions of AI tools and their capabilities, limitations, and evolving best practices for responsible use.
Since this field is moving fast, work as a team to stay updated on new versions of AI tools and best practices. One important concept to integrate into your workflows is the use of model cards. Model cards are essentially standardized documents that provide transparency about a machine learning model. Think of them as nutrition labels for AI models. They typically include details about:
What the model is, its version, and when it was developed
The specific use cases the model was designed and tested for
Scenarios where the model should not be used, due to limitations or potential for harm
How well the model performs on various benchmarks, including evaluations for fairness and bias across different demographic groups
Information about the datasets used to train the model, including any known limitations or biases in the data
Potential risks and societal implications and any mitigation strategies employed
Whenever you are using a pretrained model or evaluating a model for use, look for its model card. If you are fine-tuning or developing models, creating your own model cards is a best practice.
设置护栏和安全网。
负责任的设计实践意味着你的AI生成系统应该具备安全机制。例如,如果AI建议的越界索引修复方案可能会掩盖潜在问题,那么系统安全失效总比导致静默错误要好。如果AI生成的推荐系统可能出错,提供用户纠正或覆盖其建议的途径体现了对用户自主权的尊重。努力构建能够在AI组件出现故障时优雅降级的系统。
Create guardrails and safety nets.
Practicing responsible design means that your AI-generated systems should have safety nets. For example, if AI suggests an out-of-bounds index fix that might mask an underlying issue, it’s better for the system to fail safely than to cause silent errors. If an AI-generated recommendation system might be wrong, providing ways for users to correct or override it shows respect for their human agency. Strive to build systems that degrade gracefully if AI components misbehave.
记录团队内部的AI使用决策。
记录你使用(或不使用)某些 AI 建议的原因:“我们尝试在模块 X 中使用 AI,但它往往会生成太多重复代码,所以我们手动编写了那部分代码。” 这有助于你改进流程,让新团队成员了解 AI 在代码库历史中的作用,并增强团队的集体记忆。在审计过程中,它也可能很有用。
Document AI usage decisions within your team.
Keep an internal log of why you used certain AI suggestions (or didn’t): “We tried AI for module X, but it tended to produce too much duplicate code, so we wrote that part manually.” This can help you refine your processes, provide context to new team members about AI’s role in the codebase’s history, and augment your team’s collective memory. It can also be useful during audits.
要保持警惕人工智能使用可能导致以下后果的迹象消除歧视,并努力避免此类情况发生。例如,如果你的应用面向全球用户,你的人工智能是否支持多语言,还是更偏爱英语用户?你的所有团队成员是否都能平等地使用人工智能工具和接受培训?
Proactively work to avoid bias, discrimination, and unfairness.
Be vigilant for signs that your AI usage could lead to discrimination, and work to avoid such situations before they happen. For example, if your app is global, is your AI multilingual or does it favor those who speak English? Do all of your team members have equal access to AI tools and training?
随着人工智能领域的持续发展和变化,软件行业很可能会推出人工智能标准或认证。虽然现在还处于早期阶段,但您的公司可以通过参与标准化工作,例如加入IEEE或ISO的人工智能软件工程工作组,来帮助制定这些准则。从伦理角度来看,让开发者社区参与制定规则,比完全依赖监管机构或法院要好得多。
As the AI landscape continues changing and growing, the software industry is likely to introduce AI standards or certifications. It’s early, but your company could even help shape those guidelines by engaging in standardization efforts, like IEEE or ISO working groups on AI software engineering. Ethically, it’s better for the dev community to help set the rules than to leave it solely to regulators or the courts.
负责任的“氛围编码”是指将人工智能融入软件开发生命周期,并尊重所有利益相关者:原创作者(尊重其知识产权)、同事(通过透明和公平)、用户(通过隐私、安全和结果公平)以及社会(防止滥用造成危害)。它旨在充分利用人工智能的优势,同时谨慎防范其弱点。
Responsible vibe coding means integrating AI into the software development lifecycle in a way that respects all stakeholders: original creators (by respecting their IP), colleagues (through transparency and fairness), users (through privacy, security, and fairness in outcomes), and society (by not letting misuse cause harm). It’s about leveraging AI’s strengths while diligently guarding against its weaknesses.
我常说,所谓“感觉式编码”并非低质量工作的借口,也不是走捷径、违背道德的借口。作为负责人,开发者必须确保速度不会损害价值观。
I’ve often said that vibe coding is not an excuse for low-quality work. It’s not an excuse for ethical shortcuts either. As the humans in charge, developers must ensure that speed doesn’t compromise values.
接下来,第 10 章将探讨一项正在改变我们使用 AI 模型方式的新技术:自主编码代理。
Next, Chapter 10 looks at a new technology that’s changing the way we work with AI models: autonomous coding agents.
1案件信息通常可以在法院案卷中找到,例如美国加利福尼亚州北区地方法院和第九巡回上诉法院的案卷,或者通过法律新闻媒体和案件跟踪器找到。
1 Case information can often be found on court dockets, like those for the US District Court for the Northern District of California and the Ninth Circuit Court of Appeals, or through legal news outlets and case trackers.
2.存在一些合乎伦理的例外情况。渗透测试人员和安全研究人员可以合乎伦理地使用人工智能来发现需要修复的漏洞,只要他们遵守负责任的信息披露协议。
2 There are some ethically justified exceptions. Penetration testers and security researchers can ethically use AI to find vulnerabilities that should be fixed, as long as they work under responsible disclosure protocols.
自主后台编码代理正在迅速崛起,成为人工智能编码工具的下一个发展阶段。 与常见的边输入边提供代码建议的“副驾驶”助手不同,这些代理更像是后台的初级开发人员,您可以派遣他们异步处理整个任务。代码在为代理启动的独立环境中生成,可以运行测试,结果通常会以完整的拉取请求的形式返回给您进行审核。
Autonomous background coding agents are rapidly emerging as the next evolution of AI coding tools. Unlike familiar “copilot” assistants that suggest code while you type, these agents operate more like background junior developers you can dispatch to handle entire tasks asynchronously. Code is generated in an isolated environment spun up for the agent, tests can be run, and the result often comes back as a fully formed pull request for you to review.
在本节中,我将探讨后台编码代理的概念、工作原理、当前工具概况(OpenAI Codex、Google Jules、Cursor、Devin 等),以及它们与传统 IDE 内置助手的比较。我还会分析它们的功能、局限性,以及它们预示着软件工程未来发展方向的切实变化。
In this section, I’ll explore what background coding agents are, how they work, the current landscape of tools (OpenAI Codex, Google Jules, Cursor, Devin, and more), and how they compare to traditional in-IDE assistants. I’ll also examine their capabilities, limitations, and the pragmatic changes they signal for the future of software engineering.
传统的 AI 编码助手(如 Cursor、GitHub Copilot 或 VSCode 扩展程序如 Cline)是受监督的编码代理——交互式助手,可以响应开发人员的提示或内联上下文。它们本质上是功能强大的自动补全功能,可以在聊天或写作过程中生成建议,但每一步都由人类开发者掌控。
Traditional AI coding assistants (like Cursor, GitHub Copilot, or VSCode extensions like Cline) are supervised coding agents—interactive helpers that respond to a developer’s prompts or inline context. They’re essentially autocomplete on steroids, generating suggestions in a chat or as you write, but the human developer is in the driver’s seat guiding every step.
相比之下,自主后台编码代理的运行独立性要高得多。你只需给它们设定一个高层次的任务或目标,然后“派它们去”独立解决问题,无需持续监督。这些代理会读取并修改你的代码库,制定计划,执行代码(甚至运行测试或命令),并生成结果(通常是提交或拉取请求)——所有这些都在一个异步工作流程中完成。
In contrast, autonomous background coding agents operate with much greater independence. You give them a high-level task or goal, then “send them off” to work through the problem on their own, without constant supervision. These agents will read and modify your codebase, formulate a plan, execute code (even running tests or commands), and produce a result (often a commit or pull request)—all in an asynchronous workflow.
想想副驾驶和自动驾驶仪的区别:你的副驾驶(很像 GitHub Copilot)始终在你身旁的驾驶舱内,等待你的指令;而自动驾驶仪(后台代理)则可以在一段时间内自主驾驶飞机。这种自主性意味着后台代理可以处理多步骤的编码任务,而你可以专注于其他事情。使用像 Codex 这样的异步代理朱尔斯是就像扩展你的认知带宽一样:你可以向人工智能发送任务,然后就可以安心等待任务完成。你不再需要与人工智能进行单线程的来回交互,而是拥有了多线程的工作流程:人工智能会与你并行工作,就像一位经验丰富的初级开发人员在后台协助你一样。
Think of the difference between a copilot and an autopilot: your copilot (much like GitHub Copilot) is always in the cockpit beside you, awaiting your input; the autopilot (background agent) can fly the plane on its own for a while. This autonomy means that background agents can tackle multistep coding tasks while you focus elsewhere. Using async agents like Codex and Jules is like expanding your cognitive bandwidth: you can fire off a task to the AI and forget about it until it’s done. Instead of a single-threaded back-and-forth with an AI, you suddenly have a multithreaded workflow: the agent works in parallel with you, much like a competent junior dev working in the background.
至关重要的是,后台代理在隔离的开发环境(通常是云虚拟机或容器)中运行,而不是直接在您的编辑器中运行。他们通常会将您的代码仓库克隆到沙箱环境中,安装依赖项,并提供构建和测试项目所需的工具。出于安全考虑,这些沙箱环境受到严格限制(例如“除非明确允许,否则禁止访问互联网”),并且是临时性的。代理程序可以运行编译器、测试、代码检查器等工具,而不会对您的本地计算机造成任何风险。任务完成后,代理程序会输出代码更改(差异)以及执行操作的摘要。通常,这会以拉取请求的形式提交(包含代码差异、提交消息,有时还会附带解释),您可以对其进行审核和合并。
Crucially, background agents operate in isolated development environments (often cloud VMs or containers) rather than directly in your editor. They typically clone your repository into a sandbox, install dependencies, and have the tools needed to build and test the project. For security, these sandboxes are restricted (with rules like “No internet access unless explicitly allowed”) and ephemeral. The agent can run compilers, tests, linters, and the like without any risk to your local machine. When the task is complete, the agent outputs the code changes (diffs) and a summary of what it did. Usually this comes through as a pull request (with code diffs, commit message, and sometimes an explanation), which you can then review and merge.
总而言之,后台编码代理是一个由人工智能驱动的自主编码程序,它能够理解你的意图,在沙盒环境中通过读写代码和测试来完成整个任务,然后将结果交付给你审核。它不只是提供一两行代码的建议——它还可以处理更大规模的任务:
To sum up, a background coding agent is an AI-powered autonomous coder that understands your intent, works through an entire task in a sandbox environment by reading and writing code and testing it, and then delivers the results for you to review. It’s not just suggesting a line or two—it can handle larger-scope tasks:
在整个代码库中编写新功能 X。
Write a new feature X across the codebase.
重构模块 Y 以提高效率。
Refactor module Y for efficiency.
升级此项目的依赖项。
Upgrade this project’s dependencies.
这是我们将人工智能融入开发工作流程方式的重大转变,从提供辅助建议转向委派实际的实施工作。
This is a significant shift in how we might incorporate AI into development workflows, moving from assistive suggestions to delegating actual implementation work.
大多数后台代理在底层都遵循类似的运行模式:计划、执行、验证和报告。让我们一起来了解这些步骤及其功能。
Under the hood, most background agents follow a similar pattern of operation: plan, execute, verify, and report. Let’s walk through these steps and their capabilities.
当你给代理布置任务时(通常是通过描述你想要什么的提示或命令),代理首先解析请求并制定行动计划。有些智能助手会在执行任务前明确地向您展示执行计划。例如,谷歌的 Jules会在开始编码前提供一个执行计划供您查看和调整,这“避免了您担心助手是否正确理解了您的请求”。优秀的智能助手会将任务分解成多个子步骤:
When you give an agent a task (typically via a prompt or command describing what you want), the agent first parses the request and formulates a plan of attack. Some agents explicitly show you this plan before proceeding. For example, Google’s Jules presents an execution plan that you can review and tweak before it starts coding, which “prevents the anxiety of wondering whether the agent understood your request correctly.” A good agent will break the task into substeps:
步骤 1:在代码库中搜索相关部分;步骤 2:修改文件 A、B、C;步骤 3:运行测试;步骤 4:提交更改。
Step 1: search the codebase for relevant sections; Step 2: make changes in files A, B, C; Step 3: run tests; Step 4: commit changes.
规划阶段是实现有效自主的关键:这是人工智能在真正投入行动之前,思考如何实现目标的方式。
This planning stage is key to effective autonomy: it’s the AI’s way of reasoning about how to accomplish your goal before diving in.
该代理会为任务启动一个专用的开发环境。例如,Jules 会“将你的代码库克隆到安全的 Google Cloud 虚拟机中”,并在其中异步运行。OpenAI 的 Codex 也类似,它会在预加载了你的代码库的独立云沙箱中运行每个任务。像 Cursor 的后台代理这样的工具使用一台远程的基于 Ubuntu 的机器,该机器可以访问互联网来安装软件包,并且可以通过 Docker 或快照进行自定义。确保环境拥有所有必需的依赖项(例如正确的语言运行时和构建工具)至关重要,但也并非易事。正如我在之前的分析中提到的,“为代理创建流畅的启动体验,使其能够恰到好处地启动,是关键所在……而配置环境的用户体验即便不是比 CI 流水线更令人沮丧,也至少与之不相上下。”尽管如此,代理正在通过允许配置文件指定设置步骤来解决这个问题。其目标是在云端创建一个开发环境,使其能够模拟人类开发人员成功运行项目代码和测试所需的环境。
The agent launches a dedicated development environment for the task. Jules, for instance, “clones your codebase into a secure Google Cloud VM” and works asynchronously there. OpenAI’s Codex similarly runs each task in its own cloud sandbox, preloaded with your repository. Tools like Cursor’s background agents use a remote Ubuntu-based machine that has internet access to install packages and can be customized via Docker or snapshots. Ensuring the environment has all needed dependencies (like the correct language runtimes and build tools) is both critical and nontrivial. As I noted in a previous analysis, “Figuring out a smooth experience to spin up just the right environment for an agent is key…and the user experience to configure it is as frustrating, if not more, than it can be for CI pipelines.” Nonetheless, agents are tackling this by allowing configuration files to specify setup steps. The goal is to create a dev environment in the cloud that mirrors what a human developer would need to successfully run the project’s code and tests.
值得注意的是,许多代理程序在设置完成后会禁用其代码的互联网访问权限,从而实现沙盒运行,防止未经授权的数据泄露或不受限制的互联网调用。有些代理程序则允许在特定情况下使用受控的互联网:例如,OpenAI 最近为 Codex 任务(例如获取软件包更新或文档)启用了可选的互联网访问权限。
Notably, many agents disable internet access to their code after setup, so they can sandbox the run without unauthorized data exfiltration or unrestricted internet calls. Some allow controlled internet use for specific needs: for example, OpenAI recently enabled optional internet access for Codex tasks like fetching package updates or documentation.
接下来是重头戏:代理人开始按照计划编写和修改代码。它配备了一个大型语言模型(或多种模型的组合),该模型经过精心调校,适用于编码,可以读取多个文件、生成新代码,甚至在需要时创建新文件。在这里,智能体本质上扮演着程序员的角色:定位需要修改的地方、编辑代码并插入新的逻辑。
Next comes the main show: the agent starts writing and modifying code according to the plan. Armed with a large language model (or a mix of models) fine-tuned for coding, it can read multiple files, generate new code, and even create new files if needed. This is where the agent essentially acts like a programmer: locating where changes should be made, editing code, and inserting new logic.
早期运行中一个有趣的观察结果是,代理经常使用暴力文本搜索(如 Unixgrep命令)来查找代码库的相关部分。例如,代理程序可能会搜索函数名或关键字,以确定需要在代码库的哪个位置进行更改。这看起来过于简单——难道不应该使用更高级的语义代码搜索或基于抽象语法树(AST)的分析吗?然而,这种方法却高效可靠。正如Birgitta Böckeler 指出的那样,许多编码代理默认采用直接的全文搜索,或许是因为他们认为这是最广泛有效的方法,尽管存在更先进的技术。
One interesting observation from early runs is that agents often use brute-force text search (like the Unix grep command) to find relevant parts of the codebase. For example, an agent might search for a function name or a keyword to figure out where in the repository to make changes. This seems surprisingly simplistic—shouldn’t they use fancy semantic code search or AST-based analysis? Yet, it’s effective and reliable. As Birgitta Böckeler notes, many coding agents default to straightforward full-text search, perhaps finding it the most broadly effective method despite more advanced techniques existing.
当代理编辑代码时,一些系统会提供实时日志或状态更新,以便您可以根据需要进行跟踪。OpenAI Codex 公开了智能体在执行任务时“想法”和命令(摘要)的日志。Cursor 允许您“查看代理的状态并进入代理运行所在的机器”,以便观察甚至在任务进行过程中进行干预。但实际上,其理念是您无需时刻监控——您可以让代理自动运行。
As the agent edits code, some systems provide real-time logs or status updates so you can follow along if you want. OpenAI Codex exposes a log of the agent’s “thoughts” and commands (summarized) as it works through a task. Cursor allows you to “view their status and enter the machine the agent is running in” to observe or even intervene midtask. In practice, though, the idea is you don’t need to babysit—you can let the agent run on autopilot.
这些代理的一个显著特点是,它们不仅编写代码,还经常编译代码并运行测试来验证其更改。例如,OpenAI 的 Codex 旨在迭代运行测试,直到获得通过结果。如果一个智能体能够运行项目的测试套件(或至少是相关的测试子集),它就能发现错误并在后续迭代中自动纠正。这意义重大:它使人工智能的功能从仅仅生成代码扩展到调试和验证代码。
A defining capability of these agents is that they don’t stop at writing code—they often compile the code and run tests to verify their changes. For instance, OpenAI’s Codex is designed to iteratively run tests until it receives a passing result. If an agent can run the project’s test suite (or at least a relevant subset of tests), it can catch mistakes and automatically correct them in subsequent iterations. This is huge: it moves the AI from just generating code to also debugging and validating its code.
理论上,配备强大测试框架的智能体可以尝试修复问题,发现测试失败后调整代码,并循环执行直到测试通过——整个过程无需人工干预。但在实践中,环境问题有时会阻碍这一过程。我研究过的一个案例中,由于环境不匹配(缺少某些工具),Codex 无法运行完整的测试套件,导致提交的拉取请求中仍然有两个测试失败。如果环境完全匹配,智能体本可以在提交拉取请求之前修复这些小问题。
In theory, an agent with a robust test harness can attempt a fix, see a test fail, adjust the code, and loop until tests pass—without a human in the loop. In practice, environment issues sometimes thwart this. In one case I studied, Codex wasn’t able to run the full test suite due to environment mismatches (certain tools were missing), resulting in a pull request that still had two failing tests. Had the environment been fully aligned, the agent could have fixed those trivial issues before making the PR.
这就凸显了环境设置对自主代理的重要性:如果它们能够运行开发人员会运行的所有程序(代码检查、测试、构建),它们就可以自动纠正许多错误。像 Devin 这样的代理非常重视这个循环——Devin 会“编写代码、查找代码中的错误、修正代码,并运行自己的端到端测试来验证其功能”,这是其日常运营的一部分。事实上,Devin 甚至会启动一个它构建的前端应用程序的实时预览部署,以便您可以在浏览器中手动验证某个功能,这巧妙地扩展了验证步骤。
This underscores why environment setup is so important for autonomous agents: if they can run everything a developer would (linters, tests, builds), they can self-correct many errors automatically. Agents like Devin emphasize this loop—Devin “writes code, finds bugs in the code, corrects the code, and runs its own end-to-end tests to verify it works” as a normal part of its operation. In fact, Devin will even spin up a live preview deployment of a frontend app it built so you can manually verify a feature in the browser, which is a clever extension of the verification step.
一旦代理程序找到候选解决方案(所有测试均已通过,或者它认为代码已准备就绪),它就会为您准备结果。根据平台的不同,这可能以 GitHub 上的 PR、差异比较和解释的形式呈现。在聊天中,或准备合并的文件。
Once the agent has a candidate solution (all tests have passed, or it deems the code ready), it prepares the results for you. Depending on the platform, this might come as a PR on GitHub, a diff and explanation in chat, or files ready to merge.
此时,由您——也就是人——进行审核。这里我们又回到了“信任但要验证”的原则:您信任智能体能够生成有用的结果,但您需要通过代码审查和额外的测试来验证这些更改。许多智能体系统都明确地与 PR 审核流程集成,因为这是开发者熟悉的工作流程。例如,Jules 可以接入你的 GitHub,并创建一个分支和 PR 来提交更改。OpenAI 的 Codex 则会在 ChatGPT 中显示差异,供你批准或提出后续问题。如果你发现问题或有变更请求,通常可以将其反馈给智能体,以便进行下一次迭代。
At this point, you—the human—do a review. Here we come back to “Trust but verify”: you trust the agent to produce something useful, but you verify the changes through code review and additional testing. Many agent systems explicitly integrate with the PR review process because it’s a familiar workflow for developers. Jules, for example, plugs into your GitHub and will open a branch and PR with its changes. OpenAI’s Codex presents the diff inside ChatGPT for you to approve or ask follow-up questions. If you find issues or have change requests, you can often feed that back to the agent for another iteration.
有些智能体通过聊天来处理反馈(例如,Devin 可以从关联的 Slack 讨论串中获取反馈:如果您指出问题或提出调整建议,它会“开始撰写回复”来解决)。其他智能体可能需要使用调整后的提示重新运行一次,或者使用评论界面。令人印象深刻的是,Devin 甚至回复了一条 GitHub PR 评论,询问它为何做出某些更改——它用一个“眼睛”表情符号表示已看到该评论,然后发布了详细的解释。(虽然该解释最终被证明并不完全正确,但它能够讨论 PR 的事实表明,这些智能体可以变得多么具有互动性。)
Some agents handle this via chat (Devin can take feedback from a linked Slack thread: if you point out a problem or ask for tweaks, it will “start working on a reply” to address it). Others might require a new run with an adjusted prompt or use a review comment interface. Impressively, Devin even responded to a GitHub PR comment asking why it made certain changes—it reacted with an “eyes” emoji to signal it saw the comment, then posted a detailed explanation of its reasoning. (The explanation turned out to be not entirely correct in that case, but the fact that it can discuss PRs says something about how interactive these agents can become.)
如果一切顺利,就合并代理的 PR 或集成更改。如果不行,可以放弃它,或者让代理重试。团队面临的一个实际问题是:如果代理的输出几乎完美,但还差一点,该怎么办?是否应该花时间修复代理生成的补丁的最后 10% 到 20%,即使这是一项优先级较低的任务,你把它交给了AI?这就是我所说的 AI 贡献的“沉没成本”困境。Birgitta Böckeler认为,如果代理的 PR 只部分成功,团队就必须决定“在哪些情况下应该放弃该 PR,在哪些情况下应该投入时间来完成最后 20%”,而这项任务最初并不值得花费太多开发时间。这个问题没有标准答案——这取决于更改的背景和价值——但这是自主代理引入的一种新型权衡。
If all looks good, you merge the agent’s PR or integrate the changes. If not, you might discard it or have the agent try again. One pragmatic question teams face is what to do if an agent’s output is almost good but not quite. Do you spend time fixing up the last 10%–20% of an agent-generated patch, even if it was a low-priority task you offloaded to the AI? This is what I call the “sunk cost” dilemma for AI contributions. Birgitta Böckeler muses that if an agent PR only partly succeeds, teams will have to decide “in which situations would [they] discard the pull request, and in which situations would they invest the time to get it the last 20% there” for a task that originally wasn’t worth much dev time. There’s no one answer—it depends on the context and value of the change—but it’s a new kind of trade-off introduced by autonomous agents.
总而言之,后台编码代理负责处理编码任务的端到端周期:理解 → 计划 → 编码 → 测试 → 交付。它们本质上模拟了勤奋、有条理的开发人员在被分配任务时可能采取的做法,尽管受到当前人工智能技术的限制(参见图 10-1)。
In summary, background coding agents handle the end-to-end cycle of coding tasks: understand → plan → code → test → deliver. They essentially simulate what a diligent, methodical developer might do when assigned a task, albeit within the current limits of AI (see Figure 10-1).
有必要明确区分编码与编码之间的界限。我们拥有的AI工具有过去几年里,GitHub Copilot、ChatGPT 编码模式等技术已经发展成熟,而现在新一代的自主代理也同样如此。两者都很有用,但它们扮演的角色不同,各有优缺点。
It’s worth drawing a clear line between the coding AI tools we’ve had for a couple years (GitHub Copilot, ChatGPT coding mode, etc.) and this new generation of autonomous agents. Both are useful, but they play different roles and have different strengths/weaknesses.
最明显的区别在于他们的自主程度。IDE内置助手类似 Copilot 或 VSCode 的 AI 扩展程序会与您同步工作——它们会在被调用时生成建议或回答问题,其作用范围通常仅限于当前上下文(例如您正在编辑的文件或函数,或者您给出的特定提示)。您可以决定何时接受建议、请求其他建议或应用更改。
The most obvious difference is their level of autonomy. In-IDE assistants like Copilot or VSCode’s AI extensions work synchronously with you—they generate suggestions or answer questions when invoked, and their scope is usually limited to the immediate context (like the file or function you’re editing or a specific prompt you gave). You decide when to accept a suggestion, ask for another, or apply a change.
有了后台代理,一旦你点击任务的“开始”按钮,代理就会自主执行数百个操作(文件编辑、运行、搜索等),无需进一步确认。它是异步运行的。这需要更高的信任度(你允许它自行更改),但也让你摆脱了微观管理的束缚。我经常把它比作团队中拥有人工智能结对程序员和人工智能助手开发人员之间的区别。结对程序员(Copilot)会与你逐键协作;助理开发人员(Codex/Jules/等)则并行处理另一个问题。
With background agents, once you hit “go” on a task, the agent will autonomously perform potentially hundreds of actions (file edits, runs, searches) without further confirmation. It’s operating asynchronously. This requires a higher degree of trust (you’re letting it change things on its own) but also frees you from micromanaging. I often describe it as the difference between having an AI pair programmer versus an AI assistant developer on the team. The pair programmer (Copilot) is with you keystroke by keystroke; the assistant dev (Codex/Jules/etc.) works in parallel on another issue.
AI 工具的辅助模式意味着它们擅长处理微任务——编写函数、补全一行代码、生成一小段代码、回答关于如何使用 API 的问题。它们无法理解长远的叙事或项目全局,只能处理编辑器中打开的文件或有限窗口中的内容。
The copilot style of AI tools means they excel at microtasks—writing a function, completing a line, generating a small snippet, answering a question about how to use an API. They don’t maintain a long narrative or project-wide understanding, beyond what’s in your editor’s open files or a limited window.
自主代理在项目层面运行。它们会加载你的整个代码仓库(或者至少会为其建立索引),并能跨多个模块进行协调更改。它们会跟踪多步骤计划。例如,GitHub Copilot 可能会在你提示时帮助你编写单元测试,但后台代理可以自行决定在一个文件中添加相应的实现,在另一个文件中添加测试,并在第三个文件中添加修改后的配置——所有这些都作为一个统一的任务的一部分。这使得代理更适合重构横切关注点(日志记录、错误处理)、执行升级(通常涉及多个文件)或实现涉及后端和前端的功能等任务。IDE 助手难以处理这些任务,因为它们缺乏长期任务记忆和对整个代码仓库的可见性。
Autonomous agents operate at the project level. They load your entire repository (or at least index it) and can make coordinated changes across multiple modules. They keep track of a multistep plan. For example, GitHub Copilot might help you write a unit test if you prompt it, but a background agent could, on its own, decide to add the corresponding implementation in one file, the test in another, and a modified a config in a third—all as part of one unified task. This makes agents far better suited for things like refactoring a cross-cutting concern (logging, error handling), performing upgrades (which often involve many files), or implementing a feature that touches backend and frontend. IDE assistants couldn’t easily handle those because they lack long-term task memory and whole-repo visibility.
Copilot 式助手是响应式的——它们会响应你的代码或查询。它们不会主动发起行动。后台代理则具有主动性,一旦被激活,它们就会主动采取行动来实现目标。朱尔斯或Devin 代理可能会自行决定“我需要在这里创建一个新文件”或“现在运行测试”,而无需在每个步骤中都明确告知。它们还可以主动通知您一些事项,例如:
Copilot-style assistants are reactive—they respond to your code or queries. They don’t initiate actions. Background agents are proactive in the sense that once activated, they will take initiative to reach the goal. A Jules or Devin agent might decide, “I need to create a new file here” or “Let me run the tests now,” without being explicitly told at each step. They also can notify you of things proactively, like:
我找到了另一个可以应用此更改的地方,所以我也会把它加上去。
I found another place to apply this change, so I’ll include that too.
它们的行为更像一名员工,可能会说:“我在查看代码时发现了 X,所以我也修复了它。” 也就是说,自主性也意味着它们可能会做出一些你意想不到或未必想要的事情。这种工具的监督性质意味着它只会执行你认可的操作(除非出现你没有注意到的细微错误)。因此,权力越大(主动性越高),就越需要加强监督。
They behave more like an employee, who might say, “I noticed X while I was in the code, so I fixed that as well.” That said, autonomy also means they might do something you didn’t expect or necessarily want. The supervised nature of this style of tool means it will only do exactly what you accept (except maybe for subtle missuggestions you didn’t notice). So with great power (proactivity) comes the need for greater oversight.
主要区别在于:后台代理可以执行代码和命令,而传统的 IDE 助手通常不能(除非你把 ChatGPT 的代码解释器模式之类的东西算进去,但这更多是用于数据分析,而不是与项目的构建集成)。
A major difference is that background agents can execute code and commands, whereas traditional IDE assistants usually cannot (unless you count things like ChatGPT’s Code Interpreter mode, but that’s more for data analysis, not integrated with your project’s build).
代理程序会运行你的测试套件、启动你的开发服务器、编译应用,甚至可能还会部署它。它们在沙箱环境中运行,但实际上就像拥有一个可以使用终端的自动化开发人员。这彻底改变了游戏规则——它完善了验证/修复的闭环。IDE 助手可能会生成看起来合理的代码,但如果它没有实际运行,就可能出现运行时问题或测试失败。
Agents will run your test suite, start your dev server, compile the app, maybe even deploy it. They operate in a sandbox, but it’s effectively like having an automated developer who can use the terminal. This is a game changer—it closes the loop of verify/fix. An IDE helper might generate code that looks plausible, but if it didn’t actually run it, there could be runtime issues or failing tests.
使用能够运行代码的代理,输出结果实际可用的概率会更高。它还减轻了调试步骤的工作量;如果出现故障,代理可以立即尝试修复。但另一方面,这要求代理的环境必须正确(如前所述),并且可能会带来潜在的副作用。想象一下,代理正在运行数据库迁移或修改数据——通常它们处于沙盒模式,因此不会影响生产环境,但务必谨慎。
With an agent that runs the code, you have a higher chance the output is actually functional. It also offloads the debugging step; if something fails, the agent can try to fix it immediately. The flip side is this requires the agent’s environment to be correct (as discussed earlier), and it opens the door to potential side effects. Imagine an agent running a database migration or modifying data—usually they’re in sandbox mode, so this doesn’t affect production, but be careful.
GitHub Copilot 和类似的工具都集成在编辑器中,这对于流畅的编码体验非常有利。经纪人经常它还可以与项目管理和 DevOps 工具集成。例如,您可以创建一个 GitHub 问题,并让代理程序获取该问题并生成 PR,或者从某个位置触发代理程序运行。针对特定任务(例如自动修复 PR 中的 lint 错误),可以使用 CI 流水线。事实上,CodeGen 宣称其代理能够连接到问题跟踪系统,这样当问题状态变为“进行中”时,AI 代理就会开始处理。这种集成超越了 IDE 工具的功能。它暗示 AI 代理可以成为 CI/CD 循环的一部分——例如,自动尝试修复构建失败或自动为次要问题创建后续 PR。这是一种不同的协作模式:它不仅帮助开发人员编写代码,而且还作为机器人用户参与到团队的工具链中。
GitHub Copilot and tools like it live in the editor, which is great for in-the-flow coding. Agents often integrate with project management and DevOps tools, too. For example, you might create a GitHub issue and have an agent pick it up and generate a PR, or trigger an agent run from a CI pipeline for certain tasks (like autofixing lint errors on PRs). In fact, CodeGen advertises its agents’ ability to attach to issue trackers so that when an issue moves to “In Progress,” the AI agent works on it. This kind of integration is beyond what IDE tools do. It hints that AI agents could become part of the CI/CD loop—for instance, automatically attempting to fix build failures or automatically creating follow-up PRs for minor issues. That’s a different mode of collaboration: not just helping a dev write code but acting as a bot user in the team’s toolchain.
使用类似副驾驶的助手仍然感觉像是在编程,只是速度更快——你输入,它们提出建议,你接受,你测试。而使用后台代理则更像是先进行任务委托,然后再进行审查。人力投入从编写代码转移到编写好的任务描述,然后再审查生成的代码。我称之为“生成器与审查者之间的不对称性”——从头开始生成解决方案(或代码)很难,但审查和改进它却容易得多。异步代理正是利用了这一点:它们负责批量生成代码,让你可以专注于(通常速度更快的)审核和调整工作。这可以显著提高效率,但也意味着作为工程师,你需要提升代码审查和验证技能。
Using copilot-type assistants often still feels like programming, just faster—you type, they suggest, you accept, you test. Using a background agent feels more like delegation followed by review. The human effort shifts from writing code to writing a good task description and then reviewing the code produced. I call this “generator versus reviewer asymmetry”—generating a solution (or code) from scratch is hard, but reviewing and refining it is easier. Async agents capitalize on this: they handle the bulk generation, leaving you with the (typically faster) job of vetting and tweaking. This can be a productivity boon, but it also means as an engineer you need to sharpen your code review and verification skills.
代码审查一直都很重要,但现在它不仅适用于其他人类同事编写的代码,也适用于人工智能生成的代码,因为人工智能生成的代码可能存在不同的错误模式。我的原则是,对待人工智能生成的代码,应该像对待一位略显急切的初级开发人员编写的代码一样:假设其出发点是好的,能力也不错,但要仔细核查所有内容,如果代码不符合标准,不要犹豫,直接要求修改或拒绝。
Code review has always been important, but now it’s not just for other human colleagues’ code—it’s for AI-generated code as well, which might have different patterns of mistakes. My mantra is that you should treat agent-produced code as if it were written by a slightly overeager junior developer: assume good intentions and decent competence, but verify everything and don’t hesitate to request changes or reject if it’s not up to standards.
在实践中,我发现自己经常将类似 Copilot 的工具和后台代理结合使用。例如,在编写复杂的逻辑代码时,我可能会使用 Copilot 或 Cursor 的内联建议,因为我需要对这段逻辑进行严格的控制。同时,我可能会将一些次要但耗时的任务(例如更新所有 API 客户端库以支持新的端点)委托给后台代理并行处理。它们各有所长,并不互相替代。事实上,我预见到未来的 IDE 将会提供统一的体验:从“完成这行代码”到“生成一个函数”,再到“嘿,AI,请帮我实现整个任务”,一系列选项应有尽有。您可以根据任务范围选择合适的工具。
In practice, I find that I use copilot-style tools and background agents together. For instance, I might use Copilot or Cursor’s inline suggestions while I’m actively coding a complex piece of logic, because I want tight control over that logic. Meanwhile, I might delegate a peripheral but time-consuming task (like updating all our API client libraries for new endpoints) to a background agent to handle in parallel. They fill different niches. One doesn’t necessarily replace the other. In fact, I foresee IDEs offering a unified experience: a palette of options from “Complete this line” to “Generate a function” to “Hey, AI, please implement this entire ticket for me.” You’d choose the tool depending on the scope.
到目前为止,我常常把“人工智能”当作一个单一的整体来谈论。但实际上,人工智能模型有很多种,每种模型都有其独特的优势。有些人工智能擅长自然语言理解,有些擅长代码生成,还有一些可能专精于特定领域(例如数学问题求解器或用户界面生成器)。一位资深的Vibe编码实践者可以协调多个人工智能协同工作,让每个人工智能发挥其所长。这就像拥有一支专家团队,而不是一个通才。
So far, I’ve often referred to “the AI” as if it’s one monolithic assistant. In reality, there are many AI models, each with different strengths. Some are great at natural language understanding, others excel at generating code, and some might be specialized in certain domains (like a math problem solver or a UI generator). An advanced practitioner of vibe coding can orchestrate multiple AIs together, using each for what it’s best at. This is like having a team of specialists rather than a single generalist.
设想一下未来的工作流程,其中:
Consider a future workflow where you have:
一款经过高度编程训练的代码生成人工智能,能够高效地生成代码和修复代码。
A CodeGen AI highly trained on programming that can produce code and fix code efficiently
TestGen AI 是一款专门用于生成测试用例和查找边界用例的 AI 开发工具。
A TestGen AI, specialized in generating test cases and finding edge cases
一款能够撰写清晰文档和解释的文档人工智能
A Doc AI that writes clear documentation and explanations
一款擅长生成用户界面布局或图形的设计人工智能
A Design AI that’s skilled at generating UI layouts or graphics
一款专注于性能调优的优化人工智能,甚至可能了解底层细节。
An Optimization AI focused on performance tuning and perhaps even aware of low-level details
您可以将任务通过多个人工智能系统进行处理。例如,您可以让代码生成人工智能 (CodeGen AI) 编写代码实现。然后,您可以立即将生成的代码交给测试生成人工智能 (TestGen AI) 来生成测试用例(或进行测试评估)。接下来,您可以将代码和测试用例都交给文档生成人工智能 (Doc AI) 来生成文档或使用指南。如果代码涉及用户界面,则可以先使用设计人工智能 (Design AI) 来提出布局结构,然后再由代码生成人工智能 (CodeGen AI) 实现。通过将这些模型串联起来,您可以充分利用每个模型的领域专业知识。这类似于软件流水线或装配线,只不过这里不是不同的人工角色,而是不同的人工智能角色。
You can pipe your task through several of these AIs. For example, you ask CodeGen AI to write an implementation. Immediately, you feed that output to TestGen AI to generate tests for it (or to critique it). Then feed both code and tests to Doc AI to produce documentation or a usage guide. If the code involves user interface, maybe Design AI is used earlier to propose the layout structure that CodeGen AI then implements. By chaining them, you leverage each model’s domain expertise. This is analogous to a software pipeline or assembly line, but instead of different human roles, it’s different AI roles.
即使是相似的模型,组合使用也能提高可靠性。如果您有两个来自不同供应商或架构不同的代码生成模型,您可以让它们都尝试生成解决方案,然后比较或测试它们的输出。如果一个模型的输出通过了所有测试而另一个没有,则选择通过测试的模型。如果两个模型都通过了测试,但方法不同,您可以手动选择更易读的模型。如果一个模型失败,您甚至可以向失败的模型展示成功的代码,作为学习的提示。这种人工智能之间的交互可以减少错误,因为两个不同的模型犯完全相同错误的可能性更小。这就像获得第二意见。您已经可以找到一些研究和工具,它们使用一个人工智能来检查另一个人工智能的推理——例如,一个人工智能生成答案,另一个人工智能对其进行判断。
Even among similar models, combining them can improve reliability. If you have two code-generation models from different providers or of different architectures, you can have them both attempt the solution and then compare or test both outputs. If one model’s output passes all tests and the other doesn’t, you pick the passing one. If both pass but have different approaches, you might manually choose the more readable one. If one fails, you can even show the failing one the successful code as a hint to learn from. This kind of AI cross-talk can reduce errors since it’s less likely that two different models will make the exact same mistake. It’s like getting a second opinion. You can already find research and tools that use one AI to check another’s reasoning—for instance, one generates an answer and another judges it.
选择合适的工具来完成工作。大型语言模型(LLM)是优秀的通用模型,但有时规模较小、更专业的模型或工具效果更好。例如,对于算术运算或某些算法,确定性工具(或约束更严格的AI)可能更合适。一些高级开发环境会针对特定子任务使用符号求解器或较早的基于规则的AI,而对其他任务则使用逻辑逻辑模型(LLM)。作为一名高级Vibe程序员,你可能会维护一个工具箱:需要正则表达式时,调用一个专门的正则表达式生成器;需要提交信息时,或许可以使用一个针对摘要进行微调的模型。妙处在于,这些工具可以通过简单的脚本或提示符包装器集成起来。例如,你可以编写一个本地脚本,ai_regex_generator在内部提示AI,但会进行一些预处理和后处理,以确保输出是有效的正则表达式,并可能使用提供的示例进行测试。
Use the right tool for the job. Large language models (LLMs) are good generalists, but sometimes smaller, specialized models or tools do better. For example, for arithmetic or certain algorithms, a deterministic tool (or an AI that’s more constrained) might be better. Some advanced dev setups use symbolic solvers or older rule-based AI for specific subtasks and LLMs for others. As an advanced vibe coder, you might maintain a toolbox: when you need regex, you call a regex-specific generator; when you need a commit message, maybe a model fine-tuned for summarization is used. The beauty is these can be integrated via simple scripts or prompt wrappers. For instance, you could have a local script like ai_regex_generator that internally prompts an AI but with some pre- and postprocessing to ensure the output is a valid regex, and maybe tests it on provided examples.
如果你发现自己经常需要组合使用不同的模型,那么你可能会使用或者构建一个编排系统,这是一种新兴的框架类型,通常被称为人工智能编排或代理。这些系统允许您定义流程;例如:
If you find yourself frequently combining models, you might use or build an orchestration system, an emerging category of frameworks often referred to as AI orchestration or agents. These systems allow you to define a flow; for example:
步骤 1:使用模型 A 来解释用户请求。
步骤 2:如果请求与数据分析有关,则使用模型 B 生成 SQL;如果与文本有关,则使用模型 C……
步骤 3:将结果输入模型 D 进行解释。
Step 1: Use Model A to interpret user request.
Step 2: If request is about data analysis, use Model B to generate SQL; if about text, use Model C…
Step 3: Feed the result to Model D to explain it.
如果您正在构建一个由多个 AI 步骤驱动的应用或服务,这一点就显得尤为重要。但即使是个人开发,您也可以编写脚本来实现多步骤流程。例如,一个自定义 CLI 工具ai_dev_assist可以接收用户提示,并在后台使用 AI 将提示分类为诸如“需要帮助”、“需要帮助”和“需要帮助”之类的类别code。design根据test分类optimize结果,它会将提示转发给相应的专业 AI。收到结果后,它可以选择将结果传递给另一个 AI 进行审核或改进。
This is more relevant if you’re building an app or service powered by multiple AI steps. But even in personal dev, you can script a multistep approach. For example, one custom CLI tool, ai_dev_assist, takes a prompt and behind the scenes uses an AI to classify the prompt into categories like code, design, test, and optimize. Based on the category, it forwards the prompt to the appropriate specialist AI. When it receives the result, it can optionally pipe the result into another AI for review or improvement.
这种元人工智能协调其他人工智能的方案听起来很复杂,但高级用户利用现有技术即可完成设置。随着集成开发环境(IDE)或云平台提供专门的支持,设置过程可能会变得更加容易。
This kind of meta-AI coordinating other AIs sounds complex, but an advanced user can set it up with current technology. It will likely get easier as we begin to see dedicated support in IDEs or cloud platforms.
谈到多元智能,我们不能忘记人类合作者。高级优秀的程序员也懂得何时让其他开发者参与进来。例如,你可以使用人工智能为某个功能生成两到三个不同的设计原型,然后将它们交给团队的用户体验设计师征求反馈。哪个原型更符合我们的品牌形象?哪个原型用起来更直观?如果人工智能编写了一段复杂的代码,你可以和一位同事一起进行代码审查,重点关注这段代码,并说明“这段代码是由人工智能编写的,所以我希望再听听其他人的意见”。从某种意义上说,“多模型”方法可以将人类视为高度高级的模型——每个实体(人类或人工智能)都有其独特的优势。未来的开发模式可能经常是人机结对编程,甚至是团队编程,其中一些“团队成员”是人工智能。
While on the subject of multiple intelligences, let’s not forget human collaborators. An advanced vibe coder also knows when to involve fellow human developers in the loop. For example, you might use AI to generate two or three different design prototypes for a feature, then bring those to your team’s UX designer for feedback. Which one aligns with our brand? Which feels intuitive? If an AI writes a complex piece of code, you might do a code review session with a colleague focusing on that piece, acknowledging that “an AI helped write this, so I want another pair of human eyes on it too.” In a sense, the “multiple model” approach can include humans as just highly advanced models—each entity (human or AI) has unique strengths. The future of development might often be human + AI pair programming or even team programming where some “team members” are AI.
想象一下用Vibe编程构建一个小型Web应用程序。您的工作流程可能如下所示:
Imagine building a small web application through vibe coding. Your workflow might look like this:
You use a UI Layout AI to generate the HTML/CSS for your page given a description (specialized in frontend).
您可以使用内容 AI 来生成所需的占位符文本或图像(例如营销文本,可能使用面向文案写作的模型)。
You use a Content AI to generate some placeholder text or images needed (like marketing text, maybe using a model geared for copywriting).
然后,您可以使用您的主要代码 AI 在 JavaScript 中生成交互式功能,并将 HTML 提供给它,以便它知道要挂钩到哪些元素 ID。
You then use your main Code AI to generate the interactive functionality in JavaScript, feeding it the HTML so it knows which element IDs to hook into.
然后,您可以要求测试 AI 为界面交互生成 Selenium 或 Playwright 测试。
You then ask a Testing AI to generate Selenium or Playwright tests for the interface interactions.
最后,您可以使用安全人工智能来扫描代码,查找常见漏洞。这可以是模型,也可以是添加了人工智能的静态分析工具。
Finally, you use a Security AI to scan the code for common vulnerabilities. This could be a model or simply a static-analysis tool augmented with AI.
这种多模型方法在一个集成流程中涵盖了前端、后端(如果有的话)、内容、测试和安全。每个人工智能负责处理其部分,而您作为协调者,则确保它们协调一致。
This multimodel approach covers frontend, backend (if there is one), content, testing, and security in one integrated process. Each AI handled its portion and you, as the orchestrator, ensured they all align.
虽然现在你可能需要手动将输出从一个工具复制到另一个工具,或者使用一些粘合脚本,但未来的集成开发环境(IDE)或许能让你配置好整个流程,使其无缝衔接。关键在于:如果你有多个AI模型可用,就不要只依赖一个。针对每个任务选择最佳模型,并让它们协同工作。这不仅能带来更好的结果,还能减少单点故障——如果一个模型在某些方面表现不佳,另一个模型可以弥补其不足。
While today you might have to manually copy outputs from one tool to another or use some glue scripts, tomorrow’s IDEs might let you configure this pipeline so it feels seamless. The key takeaway is: don’t rely on just one AI model if you have access to several. Use the best one for each job and make them work together. It leads to better outcomes and also reduces single-point failure—if one model isn’t good at something, another might cover that weakness.
组合多个人工智能模型是一项高阶举措,但它是专业化原则的合乎逻辑的延伸,而专业化原则在软件工程中早已为人熟知(例如微服务,每个服务专注于做好一件事)。在这里,每个人工智能服务也专注于做好一件事。作为一名氛围程序员,你的角色不再仅仅是人工智能的提示者,而是人工智能的指挥者。这需要更多的设置和思考,但回报是人工智能协作者们共同谱写出一曲交响乐,最终呈现出高质量的产品。
Combining AI models is an advanced move, but it’s a logical extension of specialization, a principle well known in software engineering (think microservices, each service doing one thing well). Here, each AI service does one thing well. As a vibe coder, your role expands to AI conductor, not just AI prompter. It requires a bit more setup and thought, but the payoff is a symphony of AI collaborators each contributing to a high-quality end product.
既然你已经了解了它们的工作原理,让我们来看看一些领先的例子,并比较一下它们的表现。
Now that you know how they work, let’s meet some of the leading examples and see how they stack up.
我写下这段文字时是2025年,此时的自动驾驶汽车……过去一年,编码代理领域发展迅猛,不同平台涌现出各具特色的方法。这些工具标志着编码代理的功能从被动地完成代码转变为主动的开发伙伴,能够独立执行复杂的任务。
As I write this in 2025, the autonomous coding agent landscape has rapidly evolved over the past year, with distinct approaches emerging across different platforms. These tools represent a shift from passively completing code to acting as active development partners that can execute complex tasks independently.
OpenAI 的 Codex是基于云的代理方法的典型例子,它通过 ChatGPT 的界面或开源 CLI 运行。它启动独立的沙箱环境来并行执行编码任务,涵盖从 React 升级到单元测试创建等所有方面。Codex 的独特之处在于它基于真实编码任务进行强化学习训练,使其能够遵循最佳实践,例如迭代运行测试直至通过。虽然每次运行的结果可能有所不同,但对于边界明确的任务,Codex 通常都能找到有效的解决方案。它的优势在于能够在类似持续集成 (CI) 的环境中执行实际代码,代表了第一批真正与开发流程“结对”的智能体。
OpenAI’s Codex exemplifies the cloud-based agent approach, operating through ChatGPT’s interface or an open source CLI. It spins up isolated sandboxes to execute coding tasks in parallel, handling everything from React upgrades to unit test creation. What distinguishes Codex is its reinforcement-learning training on real coding tasks, enabling it to follow best practices, like running tests iteratively until they pass. While results can vary between runs, Codex typically converges on working solutions for well-bounded tasks. Its strength lies in actual code execution within CI-like environments, representing the first wave of agents that truly “pair” with development pipelines.
Google Jules采取了不同的方法,它与 GitHub 工作流程深度集成。Jules 运行在 Google Cloud 虚拟机上,并拥有完整的代码仓库克隆,它强调可见且结构化的规划——在执行前展示其推理过程并允许修改计划。这种“先计划,后执行”的理念,结合实时反馈功能,使 Jules 更像是一个受监督的助手,而非一个黑盒自动化程序。其原生于 GitHub 的设计意味着它可以直接在团队工作环境中运行,无需切换上下文即可创建分支和 PR。该代理甚至还在尝试一些新颖的功能,例如音频变更日志,旨在实现更易于访问的代码审查流程。
Google Jules takes a different approach by deeply integrating with GitHub workflows. Running on Google Cloud VMs with full repository clones, Jules emphasizes visible, structured planning—presenting its reasoning and allowing plan modifications before execution. This “plan, then execute” philosophy, combined with real-time feedback capabilities, positions Jules as a supervised assistant rather than a black-box automation. Its GitHub-native design means it operates directly where teams work, creating branches and PRs without context switching. The agent even experiments with novel features like audio changelogs, pointing toward more accessible code review processes.
Cursor 的后台代理代表了以 IDE 为中心的方法,直接从编辑器启动,但在远程机器上执行。这种混合模型允许开发者从其指挥中心协调多个 AI 工作进程,同时保持本地控制。Cursor 提供具有可定制环境(通过environment.json或 Dockerfile)的 Ubuntu 实例,使代理程序能够完全访问互联网并安装软件包。其关键创新在于与 IDE 的无缝集成:开发者可以监控代理程序的运行进度,在需要时进行干预,并在完成后立即在本地访问更改。这种方法模糊了本地 AI 辅助和云端执行能力之间的界限。
Cursor’s background agents represent the IDE-centric approach, launched directly from the editor but executing on remote machines. This hybrid model lets developers orchestrate multiple AI workers from their command center while maintaining local control. Cursor provisions Ubuntu instances with customizable environments (via environment.json or Dockerfiles), giving agents full internet access and package installation capabilities. The key innovation is seamless IDE integration: developers can monitor agent progress, intervene when needed, and immediately access changes locally when complete. This approach blurs the line between local AI assistance and cloud execution power.
Devin将自己定位为“AI 队友”,而不仅仅是一个工具,它与 Slack、GitHub 和 Jira 等问题跟踪器集成。Devin 由Cognition Labs开发,采用定制的 AI 模型,专为长期推理和多步骤执行而优化。它擅长并行执行小型维护任务,例如错误修复、添加测试用例和代码清理,这些任务通常优先级较低。其协作式设计包括状态更新、澄清请求,甚至自动预览部署。虽然 Devin 能很好地处理简单的任务,但对于复杂的问题,仍然需要大量的人工干预,这也凸显了当前自主编码的局限性。
Devin positions itself as an “AI teammate” rather than just a tool, integrating with Slack, GitHub, and issue trackers like Jira. Built by Cognition Labs, it uses custom AI models tuned for long-term reasoning and multistep execution. Devin excels at parallel execution of small maintenance tasks like bugfixes, test additions, and linter cleanups that often get deprioritized. Its collaborative design includes status updates, clarification requests, and even automatic preview deployments. While it handles straightforward tasks well, complex issues can still require significant human intervention, highlighting the current boundaries of autonomous coding.
该领域正在迅速扩张,老牌企业和初创公司都在竞相定义这一类别。微软暗示将推出“Copilot++”,其功能超越简单的内联建议,扩展到具备智能代理能力。像CodeGen(使用Anthropic的Claude)这样的初创公司正积极争取企业客户,承诺提供“永不眠的软件工程师”。与此同时,开源项目和学术研究也在不断突破界限,探索如何使代码生成更加可靠和情境化。
The field is expanding rapidly, with both established players and startups racing to define the category. Microsoft has hinted at “Copilot++,” moving beyond inline suggestions to agent capabilities. Enterprises are being courted by startups like CodeGen (which uses Anthropic’s Claude) promising “SWEs that never sleep.” Meanwhile, open source projects and academic research continue pushing boundaries, exploring how to make code generation more reliable and contextual.
这种激增表明我们正在见证一种新的开发范式的诞生,在这种范式中,单个开发者协调多个人工智能代理,每个代理都专注于软件生命周期的不同方面。正在涌现的关键差异化因素包括:
This proliferation suggests that we’re witnessing the birth of a new development paradigm where individual developers orchestrate multiple AI agents, each specialized for different aspects of the software lifecycle. The key differentiators emerging are:
执行环境(本地或云端)
Execution environment (local versus cloud)
集成深度(IDE 与工作流工具)
Integration depth (IDE versus workflow tools)
自主程度(监督式与独立式)
Autonomy level (supervised versus independent)
目标使用场景(维护与功能开发)
Target use cases (maintenance versus feature development)
尽管自主编码代理继承了正如本书中所讨论的,人工智能辅助开发面临的基础性挑战——特别是第 3 章探讨的 70% 问题——其自主性带来了独特的复杂性,值得单独研究:
While autonomous coding agents inherit the foundational challenges of AI-assisted development, as discussed throughout this book—particularly the 70% problem, explored in Chapter 3—their autonomous nature introduces distinct complications that warrant separate examination:
与每一步都有人干预的交互式人工智能助手不同,自主智能体会做出一系列决策,这些决策会以独特的方式累积错误。当智能体误解初始需求时,它生成的不仅仅是一个有缺陷的函数:它会基于这种误解构建整个实现架构。后续的每一个决策都会强化最初的错误,从而产生我所谓的“内在一致性错误”:代码内部逻辑一致,但从根本上来说与实际需求不符。
Unlike interactive AI assistance where humans intervene at each step, autonomous agents make chains of decisions that can compound errors in unique ways. When an agent misinterprets the initial requirements, it doesn’t just generate one flawed function: it builds an entire implementation architecture on that misunderstanding. Each subsequent decision reinforces the original error, creating what I call “coherent incorrectness”: code that’s internally consistent but fundamentally misaligned with actual needs.
这种顺序决策对处理多文件变更的智能体来说尤其具有挑战性。一个实现新功能的智能体可能正确地修改了后端 API,但随后却将错误的假设传播到前端、数据库模式和测试套件中。当你审查完整的拉取请求时,理清这些相互关联的错误往往比使用传统 AI 辅助进行交互式、增量式修正所需的工作量更大。
This sequential decision making particularly challenges agents that tackle multifile changes. An agent implementing a new feature might correctly modify the backend API but then propagate incorrect assumptions through the frontend, database schema, and test suites. By the time you review the complete pull request, untangling these interconnected mistakes tends to require more effort than the interactive, incremental corrections that are possible with traditional AI assistance.
第 8 章讨论了通用的环境配置挑战,而自主代理由于其沙箱执行模型,面临着独特的难题。每次代理运行都需要启动一个与开发环境完全一致的隔离环境——这种挑战难以扩展。当多个代理同时运行时,即使环境存在细微的变化,也可能导致截然不同的结果。
While Chapter 8 discusses general environment configuration challenges, autonomous agents face unique complications from their sandbox execution model. Each agent run requires spinning up an isolated environment that precisely mirrors your development setup—a challenge that scales poorly. When you’re running multiple agents concurrently, even slight variations in the environment can lead to dramatically different outcomes.
设想这样一种场景:五个代理同时处理不同的功能。代理 A 的容器中可能运行着稍旧的 Node 版本,代理 B 可能缺少某个特定的系统库,而代理 C 的时区设置可能不同。这些差异在执行过程中不可见,但只有在开始集成它们的工作时才会显现出来,成为一些不易察觉的错误。这种代理沙箱之间的“环境漂移”代表了一种新型的集成挑战,这是单开发者工作流程中不存在的。
Consider a scenario where five agents work on different features simultaneously. Agent A might have a slightly older Node version in its container, Agent B might lack a specific system library, and Agent C might have different time zone settings. These variations, invisible during execution, surface as subtle bugs that only appear when you begin integrating their work. This “environmental drift” between agent sandboxes represents a new class of integration challenge that is absent from single-developer workflows.
自主代理有望实现并行开发,但这也带来了与人类团队动态截然不同的协调挑战。当多个代理修改重叠的代码段时,它们缺乏人类使用的隐式沟通渠道——不会像人类那样通过 Slack 快速询问“你在修改认证模块吗?”,也不会对同事的工作内容有非正式的了解。
Autonomous agents promise parallel development, but this introduces coordination challenges that are quite distinct from human team dynamics. When multiple agents modify overlapping code sections, they lack the implicit communication channels humans use—there’s no quick Slack message asking, “Are you touching the auth module?” or informal awareness of what colleagues are working on.
这将产生我称之为异步协调悖论:为了提高生产力而并行运行的代理越多,集成它们就越复杂。与人类开发者通过站会和非正式沟通进行自然协调不同,代理是独立运行的。你可能会发现代理 A 重构了一个实用函数,而代理 B 却忙于向旧版本添加新的调用,从而产生冲突。如果代理像人类开发者那样自然地了解彼此的工作,这些冲突就不会发生。
This creates what I term the async coordination paradox: the more agents you run in parallel to increase productivity, the more complex integrating them becomes. Unlike human developers, who naturally coordinate through standups and informal communication, agents operate in isolation. You might discover that Agent A has refactored a utility function, while Agent B was busy adding new calls to the old version, creating conflicts that wouldn’t occur if agents had human developers’ natural awareness of each other’s work.
代码审查期间对于所有人工智能生成的代码而言,维护仍然至关重要(如前几章所述),而自主代理则因其庞大的代码量和时间紧迫性而加剧了这一挑战。与交互式人工智能助手不同,后者的代码会随着你的工作逐步生成,而代理生成的 PR 则以完整实现的形式出现——通常是在通宵运行后同时提交多个 PR。
While code review remains essential for all AI-generated code (as discussed in previous chapters), autonomous agents amplify this challenge through sheer volume and timing. Unlike interactive AI assistance, where code arrives incrementally as you work, agent-generated PRs appear as complete implementations—often as multiple PRs arriving simultaneously after overnight runs.
这会造成一种认知过载,与审查人工提交的 PR 时遇到的情况截然不同。对于人工贡献的代码,通常可以依靠提交信息和 PR 描述来反映程序员的实际思考过程。然而,代理提交的 PR 需要你从代码本身反向推导出代理的“推理过程”。当五个代理在周一早上各自提交 500 行或更多代码的 PR 时,审查工作就从协作式的质量检查变成了更像是考古探险。
This creates a kind of cognitive overload that’s distinct from the kind you get when reviewing human PRs. With human contributions, you can often rely on commit messages and PR descriptions to reflect a coder’s actual thought processes. Agent PRs, however, require you to reverse-engineer the agent’s “reasoning” from the code itself. When five agents each deliver PRs of 500 lines or more on Monday morning, the review burden shifts from being a collaborative quality check to something more like an archaeological expedition.
或许最重要的是,自主代理以交互式人工智能工具无法企及的方式挑战着我们的信任模型。当你将任务委托给代理后便置之不理时,你实际上是在对可接受的风险进行一种隐性的押注。这与监督式人工智能辅助有着本质的区别,在监督式辅助中,你可以实时掌控一切。
Perhaps most significantly, autonomous agents challenge our trust models in ways interactive AI tools don’t. When you delegate a task to an agent and walk away, you’re making an implicit bet about acceptable risk. This differs fundamentally from supervised AI assistance, where you maintain moment-by-moment control.
考虑代理技术的安全隐患。具有代码库写入权限和执行能力的自主代理会带来独特的攻击面。被攻破或被误导的代理不仅会建议恶意代码,还会主动提交甚至部署这些代码。因此,我们针对代理的沙箱和访问控制必须比基于建议的工具(详见第 8 章)更加复杂。
Consider agentic technologies’ security implications. Autonomous agents with repository write access and execution capabilities present unique attack surfaces. A compromised or misdirected agent doesn’t just suggest bad code—it actively commits it and potentially even deploys it. Our sandboxing and access controls for agents must be correspondingly more sophisticated than for suggestion-based tools (covered in Chapter 8).
随着团队扩大智能体使用规模,正在涌现出传统人工智能辅助所不具备的新型组织模式。当提出请求的开发人员生病缺勤时,代理生成的代码“归谁所有”?如何跨团队跟踪代理资源的使用情况?如果代理长达一个月的重构项目与紧急功能开发冲突,该怎么办?
As teams scale up their agent usage, new organizational patterns are emerging that don’t exist with traditional AI assistance. Who “owns” agent-generated code when the requesting developer is out sick? How do you track agent resource usage across teams? What happens when an agent’s monthlong refactoring project conflicts with urgent feature development?
这些并非技术上的限制,而是组织上的挑战,而且是自主系统独有的。它们需要新的角色(例如代理协调员?)、新的流程(例如代理影响评估?)和新的工具(例如代理集群管理?),这些都超出了本书前几章讨论的开发者个人考量范围。
These aren’t technical limitations but organizational challenges, and they’re unique to autonomous systems. They require new roles (agent coordinators?), new processes (agent impact assessments?), and new tools (agent fleet management?) that extend beyond the individual developer considerations this book has addressed in earlier chapters.
这些智能体的自主性——它们能够独立工作、做出顺序决策并大规模运行——使它们从生产力工具转变为接近团队成员的存在。这种转变不仅需要本书讨论的技术实践,还需要我们目前才刚刚开始理解的全新协调、信任和整合框架。
The autonomous nature of these agents—their ability to work independently, make sequential decisions, and operate at scale—transforms them from productivity tools into something approaching team members. This shift demands not just the technical practices discussed throughout this book but entirely new frameworks for coordination, trust, and integration that we’re only beginning to understand.
虽然许多通用的人工智能开发实践也适用于对于自主编码代理,基于代理的开发某些方面需要特别考虑。基于使用 Codex、Jules、Devin 和 Cursor 后台代理等工具的集体经验,这些实践旨在应对将整个开发任务委托给独立运行的 AI 系统所面临的独特挑战。
While many general AI development practices apply to autonomous coding agents, certain aspects of agent-based development require specific consideration. Based on collective experience with tools like Codex, Jules, Devin, and Cursor’s background agents, these practices address the unique challenges of delegating entire development tasks to AI systems operating independently.
人工智能助手和自主代理的根本区别在于它们的范围和独立性。代理擅长处理定义明确、封装清晰且成功标准明确的任务,尤其擅长并行执行多个小型任务。理想的代理任务包括全面提升测试覆盖率、系统地更新依赖关系、批量重构以及跨多个组件实现标准化功能。
The fundamental difference between AI assistants and autonomous agents lies in their scope and independence. Agents excel at well-defined, encapsulated tasks with clear success criteria—particularly those involving parallel execution of many small tasks. Ideal agent assignments include comprehensive test coverage improvements, systematic dependency updates, bulk refactoring operations, and standardized feature implementations across multiple components.
试想一下,让AI助手帮忙编写单个测试用例和让智能体完成整个模块80%的测试覆盖率,两者之间有何区别。智能体可以有条不紊地逐个检查未测试的函数,生成相应的测试用例,运行这些用例来验证其正确性,并不断迭代,直到达到覆盖率目标。这种系统化、可衡量的工作方式正是自主智能体的优势所在。
Consider the difference between asking an AI assistant to help write a single test versus tasking an agent to achieve 80% test coverage across an entire module. The agent can methodically work through each untested function, generate appropriate test cases, run them to verify correctness, and iterate until the coverage target is met. This type of systematic, measurable work is the sweet spot for autonomous agents.
相反,那些需要做出重大架构决策、解读复杂的利益相关者需求或设计新颖算法的任务,仍然更适合由人工智能辅助的人类主导开发。关键在于识别大型任务中的哪些方面可以有效地委托给智能体,哪些方面则需要人类的判断和创造力。
Conversely, tasks that require making significant architectural decisions, interpreting complex stakeholder requirements, or designing novel algorithms remain better suited to human-led development with AI assistance. The key lies in recognizing which aspects of a larger task can be effectively delegated to agents and which require human judgment and creativity.
现代自主代理区别于Jules 通过精密的规划和执行透明功能来实现自身功能,这些功能需要用户积极参与。例如,Jules 在开始工作前展示其执行计划,或者 Cursor 显示代理活动的实时日志,这些都是基于代理的开发中特有的关键干预点。
Modern autonomous agents distinguish themselves through sophisticated planning and execution transparency features that demand active engagement. When Jules presents its execution plan before beginning work or when Cursor displays real-time logs of agent activity, these represent critical intervention points that are unique to agent-based development.
规划阶段是质量把关的关键环节。审查计划不仅要确保其正确性,还要关注其效率以及是否符合代码库规范。例如,如果 Jules 计划更新 Next.js 应用,但遗漏了关键的 webpack 配置更改,那么在规划阶段发现这个问题就能避免后续大量的返工。这种主动审查与被动代码审查有着本质区别,代表了开发者工具箱中的一项新技能。
The planning phase serves as your primary quality gate. Review proposed plans not just for correctness but for efficiency and alignment with your codebase conventions. If Jules plans to update a Next.js application but omits critical webpack configuration changes, catching this during planning prevents extensive rework later on. This proactive review differs fundamentally from reactive code review and represents a new skill in the developer toolkit.
运行时监控提供了另一层针对代理的监管。虽然您无需监控每个操作,但定期检查可以防止代理采用低效的解决方案或进行不必要的大范围更改。Cursor 能够在代理执行任务期间“进入”其环境,这体现了现代工具如何在不完全放弃自主工作流程的情况下支持干预。为了最大限度地提高效率,您需要了解何时应该干预,何时应该让代理自行纠正。
Runtime monitoring provides another layer of agent-specific oversight. While you need not watch every operation, periodic checks can prevent agents from pursuing inefficient solutions or making unnecessarily broad changes. Cursor’s ability to “enter” the agent’s environment midtask exemplifies how modern tools support intervention without completely abandoning the autonomous workflow. To maximize efficiency, you’ll need to learn when to intervene and when to let the agent self-correct.
与传统方式不同在传统的开发模式下,单个开发人员一次只能处理一项任务,而代理则实现了真正的并行开发。这种能力需要新的协调策略。当同时运行多个代理时——例如,一个代理更新依赖项,而另一个代理添加日志基础设施——必须考虑它们之间可能存在的冲突和依赖关系。
Unlike traditional development, where a single developer works on one task at a time, agents enable true parallel development. This capability requires new coordination strategies. When running multiple agents simultaneously—perhaps one updating dependencies while another adds logging infrastructure—you must consider the potential conflicts and dependencies between their work.
为每个代理设定清晰的职责范围,以最大程度地减少合并冲突。尽可能将代理分配到应用程序的不同模块或层级。考虑集成顺序:添加新功能的代理可能需要等待其他代理的基础设施改进完成。这种编排方式更像是管理一个分布式团队,而不是传统的个人开发。
Establish clear boundaries for each agent’s scope to minimize merge conflicts. Assign agents to different modules or layers of the application when possible. Consider the order of integration: an agent that is adding new features might need to wait for another agent’s infrastructure improvements to complete. This orchestration resembles managing a distributed team more than it does traditional solo development.
自主代理的引入从根本上改变了团队动态和评审流程。与审查同事精心撰写的 PR 不同,代理生成的 PR 可能包含技术上正确但风格不一致的代码。团队必须制定新的审查流程来应对这种差异。
The introduction of autonomous agents fundamentally alters team dynamics and review processes. Unlike reviewing a colleague’s carefully crafted PR, agent-generated PRs may contain technically correct but stylistically inconsistent code. Teams must develop new review practices that account for this difference.
考虑建立针对特定代理的审查清单,不仅强调正确性,还要关注是否符合团队规范和架构模式。记录在使用代理过程中发现的常见问题:例如,你选择的代理可能始终使用某些反模式,或者错失了特定的优化机会。这些经验有助于审查人员快速识别并解决重复出现的问题。
Consider establishing agent-specific review checklists that emphasize not just correctness but also alignment with team conventions and architectural patterns. Document common quirks you spot as you work with the agent: perhaps your chosen agent consistently uses certain antipatterns or misses specific optimization opportunities. This institutional knowledge helps reviewers quickly identify and address recurring issues.
或许最重要的是,自主代理能够实现一种新的迭代开发形式,其中反馈回路 这不仅仅局限于代码审查。当代理的拉取请求需要改进时,通常可以将其退回并要求提供具体指导以进行迭代。这与传统的开发方式不同,在传统开发中,将工作退回给人类同事会带来社交和时间成本。
Perhaps most importantly, autonomous agents enable a new form of iterative development in which the feedback loop extends beyond mere code review. When an agent’s pull request needs refinement, you can often send it back and ask for another iteration with specific guidance. This differs from traditional development, where sending work back to a human colleague carries social and time costs.
努力开发与你选择的智能体配合良好的提示模式。当你找到能够持续产生高质量结果的成功提示语句时,请将其记录下来。为常见任务类型创建包含所有必要上下文和约束条件的模板。这是一种专门针对智能体的提示工程,它考虑了智能体的计划、执行和修订周期,并且与通用人工智能交互截然不同。
Work to develop prompting patterns that work well with your chosen agents. When you find successful prompt formulations that consistently yield high-quality results, document them. Create templates for common task types that include all necessary context and constraints. This is a kind of prompt engineering specifically for agents that considers their planning, execution, and revision cycles, and it represents a distinct skill from general AI interaction.
目标始终未变:高效交付高质量软件。自主代理只是为实现这一目标提供了一种新的工具,您应该将其谨慎地融入现有实践中,而不是全盘替换现有方法。通过了解这些代理并利用其独特功能,同时保持严格的质量标准,团队可以在不牺牲代码质量或架构完整性的前提下,显著提高生产力。
The goal remains unchanged: delivering high-quality software efficiently. Autonomous agents simply provide a new tool for achieving this goal, one you should integrate into your existing practices thoughtfully rather than replacing established methods wholesale. By understanding these agents and leveraging their unique capabilities while maintaining rigorous quality standards, teams can realize significant productivity gains without sacrificing code quality or architectural integrity.
最后,我想重申第四章的观点:人工智能不会取代开发者,但能够有效利用人工智能的开发者很可能会取代那些不擅长此道的开发者。自主编码代理的出现正是朝着这个方向迈出的一大步——那些学会驾驭这些“无头同事”的人将能够在更短的时间内完成更多的工作。对于软件工程师来说,这是一个激动人心的时代,只要我们能够适应变化并继续坚持高标准的工作要求。工具或许在不断变化,但目标始终如一:构建可靠、高效且具有创新性的软件。有了人工智能代理的辅助(或在后台运行),我们就能以全新的方式实现这些目标——或许还能在机器人熬夜工作时睡个好觉。
To wrap up, I’ll echo a sentiment from Chapter 4: AI won’t replace developers, but developers who can use AI effectively may well replace those who can’t. The advent of autonomous coding agents is a leap in that direction—those who learn to harness these “headless colleagues” will be able to do more in less time. It’s an exciting time to be a software engineer, as long as we adapt and continue to hold our work to high standards. The tools may be changing, but the goals remain: build reliable, efficient, and innovative software. With AI agents at our side (or in the background), we have new ways to reach those goals—and perhaps get a good night’s sleep while the bots burn the midnight oil.
接下来,本书最后一章将更广泛地探讨人工智能在编码领域的未来,包括智能人工智能的未来。
Next, the final chapter of this book takes a broader look at the future of AI in coding, including the future of agentic AI.
氛围编码可能起源于人工智能生成虽然代码来自我们的提示,但它的影响远远超出了编写代码本身。随着人工智能技术的进步,它势必会彻底改变软件开发生命周期的方方面面。在本章中,我将以推测性的视角,探讨人工智能在软件领域未来可能扮演的角色。我将探讨人工智能驱动的测试、调试和维护;人工智能如何影响软件设计和用户体验个性化;人工智能辅助下的项目管理将如何演变;甚至编程语言本身的未来发展。我的目标是设想这样一个未来:人工智能不再仅仅是代码生成器,而是软件工程中不可或缺的参与者——同时,我将讨论建立在基本原理之上,以确保即使特定技术不断更迭,其意义依然不变。
Vibe coding may have started with AI generating code from our prompts, but its implications reach far beyond just writing code. As AI technologies advance, they are poised to transform every aspect of the software development lifecycle. In this chapter, I take a speculative yet informed look at how AI’s role in software might expand in the future. I will explore AI-driven testing, debugging, and maintenance; how AI could influence software design and user experience personalization; the evolution of project management with AI assistance; and even the future of programming languages themselves. The aim is to imagine a future where AI isn’t just a code generator but a holistic participant in software engineering—all while grounding the discussion in fundamental principles, so it remains relevant even as specific technologies come and go.
想象一下未来的开发环境:当你编写一个函数(无论是手动编写还是通过 Vibe 编码)时,人工智能工具就会立即介入。 它能立即为其编写一套单元测试,发现潜在的错误,甚至可能在几秒钟内修复它们。这种情况正迅速成为现实。让我们来分析一下人工智能在质量保证和维护方面的潜在贡献(以及已经显现的贡献)。
Imagine a future development environment where as soon as you write a function (whether by hand or via vibe coding), an AI tool immediately writes a suite of unit tests for it, finds potential bugs, and maybe even fixes them—all in a matter of seconds. This scenario is quickly becoming plausible. Let’s break down AI’s potential (and already emerging) contributions in quality assurance and maintenance.
编写全面的测试很耗时,而且常常因为截止日期而忽略。正如您在第 7 章中所看到的,目前的 AI 助手可以通过自动生成测试来缓解这个问题。例如,给定一段代码,AI 可以建议一组单元测试,涵盖典型用例、边界用例和错误情况。
Writing thorough tests is time-consuming and often neglected due to deadlines. As you saw in Chapter 7, current AI assistants can alleviate this by generating tests automatically. For example, given a piece of code, an AI can suggest a set of unit tests covering typical cases, edge cases, and error conditions.
未来,这项技术还可以更进一步:人工智能可以检查整个代码库,识别测试覆盖率不足的函数或模块,并生成额外的测试用例。它甚至可以模拟人类测试人员意想不到的输入(例如模糊测试),从而有可能发现一些特殊情况下的错误。其优势在于,只需极少的人工测试编写,就能构建出更健壮的代码库。
In the future, this could go further: the AI could examine your entire codebase, identify functions or modules with insufficient test coverage, and generate additional tests. It might even simulate inputs that a human tester wouldn’t think of (like fuzz testing), potentially catching corner-case bugs. The benefit is a more robust codebase with minimal manual test writing.
需要注意的是,测试的有效性取决于人工智能对规范的理解程度。因此,应该由人工审核人工智能生成的测试,以确保它们与软件的预期行为相符。例如,人工智能可能会断言某个输出在技术上符合代码的功能,但实际需求可能并非如此——只要有人参与其中,就能帮助发现代码或测试中存在的误解。
The caveat is that tests are only as good as the AI’s understanding of the specification. Thus, a human should review AI-generated tests to ensure they align with the intended behavior of the software. For instance, the AI might assert a certain output that is technically what the code does, but perhaps the requirement was different—which, as long as a human is in the loop, can actually help to catch a misunderstanding in either the code or the test.
调试通常需要费力地搜索日志或单步执行代码,以找到错误的根源。 第五章展示了人工智能如何像智能调试助手一样工作。一些现有的人工智能工具可以接收错误信息和问题代码作为输入,并返回错误解释和相应的代码修改建议。
Debugging often involves tedious searching through logs or stepping through code to locate the source of an error. Chapter 5 showed you how AI can act like a smart debugging companion. Some current AI tools can take an error message and problematic code as input and return an explanation and a code change to fix it.
为了了解人工智能辅助调试工作流程的未来发展方向,不妨设想这样一个人工智能系统:它监控程序的执行过程,当程序崩溃或出现异常时,它会分析堆栈跟踪和变量状态,从而精确定位可能的原因。它不仅会给出错误信息,还会指出:
For a glimpse of how AI-assisted debugging workflows may evolve, consider an AI system that monitors your program’s execution, and when a crash or exception happens, it analyzes the stack trace and variable states to pinpoint the likely cause. Instead of just giving you an error message, it might say:
应用程序崩溃的原因是调用 getEmail() 时 userProfiles 为空。这表明加载用户配置文件时缺少空值检查。
The application crashed because userProfiles was null when calling getEmail(). This suggests a missing null-check when loading user profiles.
此外,人工智能还可以提出解决方案:
Further, the AI could suggest a fix:
一个可能的解决方案是,如果 userProfiles 为空,则对其进行初始化;或者在调用 getEmail() 之前添加一个条件。您希望我应用此修复方案吗?
A possible solution is to initialize userProfiles if it’s null or add a condition before calling getEmail(). Would you like me to apply this fix?
未来的调试人工智能可以直接与运行时环境集成,实时捕获问题。它们甚至可以通过分析代码路径来预测问题发生之前的情况:
Future debugging AIs could integrate directly with runtime environments, catching issues in real time. They might even predict issues before they happen by analyzing code paths:
如果使用 y = 0 调用此函数,则可能会抛出 DivisionByZero 异常;请考虑处理这种情况。
This function might throw a DivisionByZero exception if called with y = 0; consider handling that case.
这类似于静态分析,但它利用人工智能学习到的无数代码库和错误模式的知识,使其可能更具洞察力或灵活性。
This is similar to static analysis but powered by the AI’s learned knowledge of countless codebases and error patterns, making it potentially more insightful or flexible.
根据要求换班随着时间的推移,代码会变得过时或不再最优。维护工作包括重构(在不改变行为的前提下改进代码结构)、更新依赖项和优化性能等活动。人工智能可以在这些方面提供帮助:
As requirements change over time, code becomes outdated or suboptimal. Maintenance involves activities like refactoring (improving code structure without changing behavior), updating dependencies, and optimizing performance. AI can assist in each of these areas:
未来的人工智能可以识别代码异味(例如重复代码或过长的函数),并自动重构它们。例如,它可能会检测到你在三个地方使用了相似的代码块,并建议将它们抽象成一个辅助函数。或者,它可以将一组嵌套很深的循环转换为更易读的形式。由于人工智能已经见过许多“优秀”代码的示例,因此它可以提出风格改进建议,以保持代码库的整洁和易于维护。未来,我们的编辑器或许会拥有这样一种模式:人工智能在后台持续重构代码,而开发者则负责审查和批准这些更改。
A future AI could identify code smells (like duplicate code or long functions) and automatically refactor them. For instance, it might detect that you have similar chunks of code in three places and recommend abstracting them into a single helper function. Or it could transform a deeply nested set of loops into a more readable form. Since the AI has seen many examples of “good” code, it can suggest stylistic improvements to keep the codebase clean and maintainable. We might one day have a mode in our editors where the AI continuously refactors code in the background, with the developer reviewing and approving changes.
未来人工智能服务它可以监控项目的依赖项(例如库和框架),并自动生成拉取请求,将它们更新到新版本,包括为适应重大变更而需要进行的任何代码更改。例如,如果新版本的 Web 框架更改了 API,AI 可以调整你的代码以适应新的 API。这将使开发人员免于重复阅读迁移指南和修复版本问题的工作。
A future AI service might monitor your project’s dependencies (such as libraries and frameworks) and automatically generate pull requests to update them to newer versions, including any code changes needed to accommodate breaking changes. For example, if a new version of a web framework changes the API, the AI could adapt your code to the new API. This would save developers the repetitive work of reading migration guides and fixing version issues.
随着数据规模或使用模式的变化,维护工作通常包括提高性能。人工智能可以通过分析性能概况并指出效率低下之处来发挥作用。例如,人工智能可能会注意到代码中的某个数据库查询耗时过长,并建议添加索引或重写查询。它也可能识别出代码中的循环正在进行冗余计算,并建议使用缓存。这就像有一位性能专家始终监控着你的应用程序——主动检测冗余循环或次优数据结构等效率低下之处。
Maintenance often includes improving performance as data scales or usage patterns shift. AI can play a role by analyzing performance profiles and pointing out inefficiencies. For example, an AI might notice that a certain database query in your code is taking a long time and suggest adding an index or rewriting the query. It might identify that a loop in your code is making redundant calculations and propose a cache. This is akin to having a performance expert always keeping an eye on your application—proactively detecting inefficiencies like redundant loops or suboptimal data structures.
人工智能可以在测试环境中运行,模拟高负载,然后生成一份报告:“在高负载下,模块 X 由于 Y 的原因成为瓶颈。请考虑使用方法 Z 进行重构。” 本质上,人工智能不仅能发现问题,还能指导团队采用更优的模式。
The AI might run in a staging environment, simulate heavy loads, and then feed you a report: “Under high load, Module X becomes a bottleneck due to Y. Consider refactoring using approach Z.” In essence, the AI not only finds issues but also educates the team on better patterns.
除了代码和逻辑之外,人工智能还是人工智能将影响我们设计软件的方式以及用户体验。优秀的软件不仅底层代码正确,还应直观易用、方便快捷,并能满足用户的需求。人工智能将不断开发新的方法,以创建更佳的用户界面,并根据用户的个性化需求定制体验。
Beyond the code and logic, AI is set to influence how we design software and how users experience it. Good software isn’t just correct under the hood; it’s also intuitive, accessible, and satisfying for users. AI will continue to develop new ways to create better user interfaces and tailor experiences to individual user needs.
如今的 AI 设计工具利用生成对抗网络或 Transformer 等技术,根据描述生成 UI 模型。产品经理可以用自然语言描述产品功能:
Today’s AI design tools use techniques from generative adversarial networks or transformers to produce UI mockups from descriptions. A product manager can describe a feature in natural language:
我们需要一个移动端注册页面,包含欢迎信息、趣味插图以及用于填写姓名、邮箱和密码的表单。页面颜色应符合我们的品牌调性,整体风格友好亲切。
We need a mobile sign-up screen with a welcome message, a playful illustration, and a form for name, email, and password. It should have our brand colors and a friendly look.
AI 设计助手可以根据这段描述,在几秒钟内生成多个候选 UI 设计方案,包括布局、占位符文本,甚至样式化的组件。然后,设计师或开发人员从中选择最接近的方案并进行完善。
An AI design assistant can take this description and generate several candidate UI designs in seconds, complete with layout, placeholder text, and even styled components. The designer or developer then picks the closest one and refines it.
未来,这些工具可以直接集成到设计软件甚至编码环境中,从而使“设计”和“编写用户界面”之间的界限变得模糊。人工智能可以直接输出其生成的设计的 HTML/CSS 或 Flutter 代码,使其能够立即进行测试。这将极大地加快设计迭代周期。您无需再手工或使用软件绘制草图,而是可以与人工智能协作,它会根据最佳实践和海量用户喜爱或易用的训练数据来提出设计方案。
In the future, these tools could be integrated directly into design software or even coding environments so that the line between “designing” and “coding the UI” blurs. The AI might directly output HTML/CSS or Flutter code for the design it generates, making it immediately testable. This would speed up the design iteration cycle tremendously. Instead of sketching by hand or in software, you’d collaborate with an AI that proposes designs based on best practices and vast training data of what users find appealing or usable.
即使在设计创作过程中,人工智能也能成为灵感缪斯。当设计师为应用程序构思配色方案或插画风格时,人工智能工具可以生成色彩情绪板,甚至可以即时创建自定义图标。例如,他们可以告诉人工智能:
Even in the creative process of design, an AI could be a muse. When a designer is brainstorming a color scheme or an illustration style for an app, an AI tool could generate a mood board of colors or even create custom iconography on the fly. For instance, they might tell the AI:
我需要一个能将代码和音乐理念结合起来的标志。
I need a logo that combines the ideas of code and music.
它会生成一些示例标志,将编码符号(例如花括号)与音符混合在一起。虽然最终的成品可能仍需专业设计师手工打造,但人工智能的建议可以激发灵感,加快探索阶段。本质上,人工智能可以扮演快速原型制作者和创意伙伴的角色,拓宽设计师的选择范围。
It would produce a few sample logos mixing symbols of coding (like curly braces) with musical notes. While a professional designer might ultimately handcraft the final asset, the AI’s suggestions can spark ideas and accelerate the exploration phase. In essence, AI can fill the role of a quick prototyper and creative partner that broadens the designer’s palate of options.
值得注意的是,在设计和用户体验领域,人类的判断至关重要。审美趣味、对人类情感的理解、品牌识别——这些都是人工智能可以近似实现但自身并不具备的。因此,人工智能在设计中是增强人类创造力的工具,而非取代它。它可以处理生成变体和处理用户数据的繁琐工作,使设计师能够专注于同理心和创意决策。
It’s important to note that in design and UX, human judgment is paramount. Aesthetic taste, understanding of human emotions, brand identity—these are things an AI can approximate but not inherently possess. Thus, AI in design is a tool to enhance human creativity, not replace it. It can handle the grunt work of producing variants and processing user data, freeing designers to focus on empathy and creative decisions.
对于开发者而言,AI驱动的设计意味着传统的开发与设计交接流程可能会变得更加流畅。开发者可以与设计师协作,利用AI生成UI代码,反之亦然。这也意味着前端开发者可以减少逐像素调整布局的时间,而将更多精力放在确保设计与功能相符且易于访问上。他们还可以致力于创建个性化接口——编写代码,让AI能够根据用户数据在布局A和布局B之间进行选择,并确保两种布局都具有良好的性能和稳定性。
For developers, AI-driven design means that the traditional handoff between design and development might become more fluid. Developers could generate UI code with AI in collaboration with designers, or vice versa. It also means frontend developers might spend less time tweaking layouts pixel by pixel and more time ensuring the design aligns with functionality and is implemented accessibly. They might also work on creating the hooks for personalization—writing code that allows the AI to choose between layout A or B based on user data and ensuring both layouts are performant and solid.
在“氛围编码”的未来,你或许也可以进行“氛围设计”:只需描述你希望应用程序外观和感觉呈现的氛围(此处双关),人工智能就能助你将其变为现实。最终,我们将迎来一个整体的人工智能开发流程——不再仅仅是借助人工智能编写后端逻辑或数据库查询,而是与人工智能携手打造完整的产品体验。
In a future of vibe coding, you might “vibe design” as well: just describe the vibe (pun intended) you want for your application’s look and feel, and AI will help materialize it. The result is a holistic AI development process—not just writing backend logic or database queries with AI assistance but crafting the whole product experience in partnership with AI.
设计的另一个方面是了解用户行为。 人工智能可以分析您应用程序的使用数据(同时兼顾隐私问题),从而找出用户遇到的困难。例如,人工智能可能会检测到许多用户将鼠标悬停在某个图标上,期望它可点击,但实际上并非如此——这表明用户体验方面存在改进空间。或者,它可能会注意到特定人群的用户经常在工作流程的某个特定步骤放弃操作,这表明该步骤对他们来说可能不够直观。
Another aspect of design is understanding user behavior. AI can analyze usage data from your application (with privacy considerations in mind) to highlight where users struggle. For instance, an AI might detect that many users hover over a certain icon expecting it to be clickable, and it’s not—indicating a UX improvement opportunity. Or it might notice that users from a certain demographic consistently drop off at a particular step of a workflow, suggesting that step might not be intuitive for them.
未来,人工智能甚至可以模拟用户交互(利用用户行为模型),在真实用户遇到问题之前预测用户体验问题。这种“虚拟用户体验测试”可以在开发过程中发现诸如过于复杂的导航或不清晰的标签等问题,从而更容易修复。
In the future, AI could even simulate user interactions (using models of user behavior) to predict UX issues before real users encounter them. This “virtual UX testing” could catch things like overly complex navigation or unclear labels during development, when they’re easier to fix.
个性化一直是热门词汇——指的是根据用户的偏好或历史记录向不同的用户提供不同的内容。人工智能可以通过实时微调软件行为和界面,将个性化提升到一个新的水平,从而更好地满足每个用户的需求。例如,应用程序的人工智能可以学习到某个用户倾向于通过搜索而非菜单来浏览应用程序。然后,人工智能可以根据用户的使用习惯进行调整,例如使搜索栏更加醒目,甚至预先加载用户可能想要的搜索结果(就像人类助理预判老板的需求一样)。
Personalization has been a buzzword for a while—in the sense of providing different content to different users based on preferences or history. AI can take personalization to the next level by fine-tuning software behavior and interfaces for each user in real time. For example, an app’s AI could learn that a particular user tends to navigate the app via search rather than menus. The AI could then adapt by making the search bar more prominent for that user or even preloading search results it expects the user might want given the context (like a human assistant anticipating their boss’s needs).
另一种情况会有所改善。辅助功能:如果人工智能检测到用户正在使用屏幕阅读器(因此可能存在视力障碍),它可以自动将应用程序切换到高对比度、大字体模式,并优化屏幕阅读器标签,其效果甚至超越了静态辅助功能设置。本质上,软件可以变得具有自适应性。
Another scenario would improve accessibility: if the AI detects a user is using screen-reader technology (and thus is perhaps visually impaired), it could automatically switch the application to a high-contrast, larger-font mode with optimized screen-reader labels, even beyond what the static accessibility settings might do. Essentially, software can become adaptive.
想象一下,一个电商网站能够实时调整布局——有些用户可能看到产品网格,而另一些用户则可能看到包含更多详细信息的列表,这取决于哪种方式更能吸引他们。随着人工智能的不断尝试和学习,这些变化可以非常细微且持续——有点像A/B测试,但它是针对个体用户自主进行的。
Imagine an ecommerce site that rearranges its layout on the fly—some users might see a grid of products and others a list with more details, depending on what seems to engage them more. These changes could be subtle and continuous as the AI experiments and learns—somewhat like how A/B testing works but on an individual level and autonomously.
软件开发并非如此只是编写代码而已人工智能不仅负责设计,还负责规划、协调和决策——这些都是项目管理和团队领导的范畴。人工智能的分析和预测能力可以极大地帮助项目管理,从任务分配到风险管理和决策支持,无所不包。以下是人工智能如何重塑我们规划和执行软件项目的方式:
Software development isn’t just writing code and making designs; it’s also planning, coordinating, and making decisions—the domain of project management and team leadership. AI’s analytical and predictive capabilities can greatly assist in managing projects, from allocation of tasks to risk management and decision support. Here’s how AI could reshape the way we plan and execute software projects:
管理团队需要了解每位开发人员的优势、劣势和当前工作量,然后据此分配任务。人工智能项目管理助手可以分析各种数据点——代码提交历史、专业领域(或许可以从开发人员参与过的代码库部分中推断出来),甚至是个人工作效率模式(有些人早上效率更高,有些人则在深夜效率更高)——并推荐谁应该承担新任务。
Managing a team involves knowing each developer’s strengths, weaknesses, and current workload, then assigning tasks accordingly. An AI project management assistant could analyze various data points—code commit history, areas of expertise (perhaps gleaned from which parts of the codebase a developer has worked on), even personal productivity patterns (some people code more effectively in the morning, others late at night)—and recommend who should tackle a new task.
例如,如果一项新功能涉及数据库工作,而人工智能知道爱丽丝已经成功完成过许多数据库相关任务且工作量并不超负荷,它可能会建议将这项任务分配给爱丽丝。此外,人工智能还可以通过将其与以往类似任务进行比较并考虑个人的工作效率,来预测这项任务所需的时间。这有助于项目经理制定更切合实际的时间表,避免任何团队成员工作量过大。随着时间的推移,这样的人工智能可以像经验丰富的经理一样学习平衡工作量,确保既不会有人闲着,也不会有人工作过度。
For example, if a new feature involves database work and the AI knows Alice has done a lot of database-related tasks successfully and isn’t overloaded, it might suggest assigning the task to Alice. Moreover, the AI could predict how long the task might take by comparing it to similar tasks in the past and considering the individual’s velocity. This helps project managers set more realistic timelines and avoid overburdening any single team member. Over time, such an AI could learn to balance the workload like a skilled manager, ensuring that no one is idle and no one is overwhelmed.
人工智能可以帮助将高层次的目标分解为可执行的具体步骤。你可以向人工智能输入功能需求或用户故事,它就能建议出实现该功能所需的一系列子任务。本质上,它可以生成一份草案计划或工作分解结构。在敏捷方法论的冲刺计划会议期间,人工智能可以分析待办事项列表,并根据团队过去的开发速度,建议哪些任务适合纳入下一个冲刺。
AI can assist in breaking down high-level goals into actionable items. You might feed the AI a feature request or a user story, and it could suggest a list of subtasks required to implement it. Essentially, it could produce a draft plan or a work breakdown structure. During sprint planning (in Agile methodologies), the AI could analyze the backlog and, given the team’s past velocity, suggest which set of tasks fits into the next sprint.
它甚至可以突出显示任务之间的依赖关系,确保计划在逻辑上有序:
It could even highlight dependencies between tasks, ensuring the plan is logically ordered:
任务 B 应该在任务 A 之后完成,因为它建立在任务 A 的功能之上。
Task B should be done after Task A, as it builds on that functionality.
对于长期发展路线图规划,人工智能工具可以模拟不同的场景:
For long-term roadmapping, AI tools might simulate different scenarios:
如果我们现在优先考虑功能 X,模型预测由于资源需求重叠,我们可能会将功能 Y 的开发推迟 2 周。
If we prioritize Feature X now, the model predicts we risk delaying Feature Y by 2 weeks due to overlapping resource needs.
借助这些模拟和数据驱动的洞察,可以帮助管理者就优先事项做出明智的决策。
Having these simulations and data-driven insights can help human managers make informed decisions on priorities.
风险管理通常涉及预测可能出现的问题——例如延误、技术难题、集成问题——并制定相应的缓解措施。人工智能非常适合模式识别,因此它可以分析历史项目数据(公司内部数据,甚至行业范围内的数据,如果可用的话),从而识别风险因素。
Risk management often involves anticipating what could go wrong—delays, technical hurdles, integration issues—and planning mitigation efforts. AI is well suited for pattern recognition, so it could analyze historical project data (within the company or even industry-wide, if available) to identify risk factors.
例如,人工智能可能会标记出以下情况:
根据历史数据,涉及技术栈切换的项目延期的可能性要高出 30%。
在过去的三个项目中,我们都在集成测试阶段出现了失误;这很可能也是本项目面临的风险。
这样一来,管理者就可以提前为这些阶段分配更多的时间或资源。另一个角度是监控当前进度:人工智能系统可以监控任务完成率、缺陷发现率等,并在检测到问题时发出警报:
For example, the AI might flag things like:
Projects involving a switch in technology stack have a 30% higher chance of running over schedule based on historical data.
We have slipped in integration testing phase in the last three projects; likely a risk for this project as well.
With this, managers can preemptively allocate more time or resources to those phases. Another angle is monitoring current progress: an AI system could watch the rate of task completion, the rate of bug discovery, etc., and send alerts if it senses trouble:
团队在本轮迭代中完成任务的速度只有预期速度的一半;需要关注可能存在的阻碍因素。
The team is closing tasks at half the expected rate this sprint; possible blockers need attention.
从本质上讲,人工智能可以成为一个时刻保持警惕的项目审计员,在问题升级之前发现它们。
Essentially, AI can be an ever-vigilant project auditor, spotting issues before they escalate.
项目管理涉及许多决策——例如是否为了赶工期而砍掉某个功能,或者是否应该投资重构而不是添加新功能——都需要人工智能来做出。人工智能无法直接做出这些决策,因为它们涉及业务和人为因素,但它可以提供数据来支持决策。例如,在讨论是否进行重构时,人工智能可能会报告:
Project management involves many decisions—like whether to cut a feature to meet a deadline or whether to invest in refactoring instead of adding new features. AI can’t make these decisions because they involve business and human factors, but it can provide data to support them. For instance, if debating a refactor, the AI might report:
如果我们根据复杂度指标和团队反馈重构模块 Z,可以将相关功能的未来开发时间缩短 20%。虽然现在可能会增加两周的延误,但六个月后就能看到成效。
If we refactor module Z, based on complexity metrics and team input, it could reduce future development time on related features by 20%. It might add a two-week delay now but pay off in six months.
虽然这些数字只是估计值,但进行客观分析有助于利益相关者更具体地权衡利弊。
While these numbers would be estimates, having an objective analysis helps stakeholders weigh trade-offs more concretely.
另一个例子是决定是采用新库还是自行开发。人工智能可以扫描该库的文档、社区支持和已知问题,并总结其优缺点,从而为团队节省大量研究时间。
Another example might be deciding whether to adopt a new library or build in-house. The AI could scan documentation, community support, and known issues about that library and summarize its pros and cons, saving the team hours of research.
Stakeholders or managers could one day query an AI in natural language about project status:
支付集成功能进展如何?遇到了哪些障碍?
How is the payment integration feature going? What are the blockers?
人工智能在解析了工单更新、提交信息和测试结果后,可能会回答:
The AI, having parsed ticket updates, commit messages, and test results, might answer:
支付集成已完成 70%。目前遇到的一个障碍是货币转换相关的测试失败,两位开发人员正在调试。如果明天能解决这个问题,该功能有望在周五完成。
The payment integration is 70% complete. One blocker is a failing test related to currency conversion, which two developers are currently debugging. If resolved by tomorrow, the feature is on track for completion by Friday.
这种易于理解的状态报告方式可以改善沟通,尤其是在大型团队或包含非技术利益相关者的团队中。人工智能基本上可以成为一个无所不知的项目助手,它了解所有细节,并能根据需要进行总结。
This kind of accessible status reporting can improve communication, especially in large teams or teams with nontechnical stakeholders. The AI basically becomes an omniscient project assistant that knows the nitty-gritty details and can summarize them as needed.
这有点推测性质,但人工智能可能此外,人工智能还可以通过分析沟通模式来评估团队士气或压力水平(当然,前提是尊重隐私和界限)。例如,人工智能可以检测到代码审查评论变得简短,或者 Jira 工单被频繁“重新打开”——这可能表明团队成员感到困惑或沮丧——并委婉地提醒项目负责人关注团队成员的状况。在远程或分布式团队中,由于此类信号难以解读,能够监控“数字情绪”的人工智能就显得尤为重要。当然,这一切都必须以谨慎和透明的方式进行,以避免给人以侵犯隐私的感觉。
This is a bit speculative, but AI could also gauge team morale or stress by analyzing communication patterns (respecting privacy and boundaries, of course). For example, an AI might detect that code review comments are becoming terse or Jira tickets are getting a lot of “reopen” actions—possibly indicating confusion or frustration—and gently alert a project lead to check in on the team’s well-being. In remote or distributed teams, where such signals are harder to read, an AI that monitors the “digital mood” could be valuable. Of course, this would have to be handled delicately and transparently to avoid feeling invasive.
在所有这些方面,人工智能都能为项目经理带来倍增效应。它能处理繁重的分析和日常建议,使项目经理能够专注于他们最擅长的领域:做出判断、激励团队以及处理协作中的人性化环节。优秀的项目管理既是一门科学,也是一门艺术;人工智能可以强化科学部分(数据、预测、分析),从而让艺术部分(领导力、远见、适应能力)得以充分发挥。开发人员也应该欢迎这些改进:一个规划完善、监控到位的项目意味着更清晰的目标和更少的意外情况。这也意味着更少的会议时间或更新电子表格的时间——因为人工智能会处理这些细节——更多的花费时间从事创意开发工作。
In all these ways, AI acts as a force multiplier for project managers. It handles the heavy analysis and routine suggestions, allowing human managers to focus on what they do best: making judgment calls, motivating the team, and handling the human side of collaboration. Good project management is as much art as science; AI can strengthen the science part (data, predictions, analysis) so that the art (leadership, vision, adaptability) can shine. Developers should welcome these enhancements too: a well-planned, well-monitored project means clearer goals and fewer nasty surprises. It also means less time in status meetings or updating spreadsheets—since the AI takes care of those details—and more time doing creative development work.
我们仍然处于……这场比赛的早期阶段科技发展日新月异。值得思考的是,这些影响具有长远意义,并且在未来几年内可能会如何发展。以下是基于当前趋势和一些有根据的推测,对自主编码代理时代软件工程未来的展望:
We’re still in the early innings of this technology, but it’s moving fast. It’s worth pondering the longer-term implications and how things might evolve in the next few years. Here’s a vision of the future of software engineering in the age of autonomous coding agents, drawing from current trends and some informed speculation:
就像如今使用源代码控制或持续集成/持续交付 (CI/CD) 已成为标准做法一样,让人工智能 (AI) 代理参与开发也可能成为一种常态。或许,每天早上查看“AI 助手看板”就能看到代理在夜间完成的任务——代码审查会在你登录时自动完成。如今,这种趋势已经初见端倪,代理会在你“睡觉时”运行。工程师们通常会在一天结束时将一批任务委托给 AI,让它们在第二天早上尝试完成。“开发人员的工作”的思维模式也将发生转变:不再是编写样板代码或进行机械式的更新,而是更多地关注定义问题、集成解决方案以及指导 AI。不妨这样说,开发人员更像是 AI 开发人员的产品经理——他们明确需要做什么,并确保其满足需求。
Just as using source control or CI/CD is standard today, having AI agents participate in development could become routine. It might be normal that, every morning, you check an “AI assistant board” showing tasks done overnight by agents—the code reviews will be waiting for you when you log in. There’s already a hint of this today, with agents running “while you sleep.” Engineers might commonly delegate a batch of tasks at day’s end for the AI to attempt by next morning. The mindset of what a “developer’s job” is will shift: less about typing out boilerplate or doing rote updates, more about defining problems, integrating solutions, and guiding the AI. You might say, to be a bit fanciful, that developers become more like product managers for AI developers—they specify what needs doing and ensure that it meets requirements.
目前,每个智能体大多独立完成你交给它的任务。但未来可能会出现多个拥有不同专长的智能体协同工作的场景。一个智能体可能擅长前端任务,另一个擅长后端任务,你可以给它们分配一个需要协调的任务(或者它们甚至可以自行找到拆分任务的方法)。此外,智能体还可以并行探索多条解决方案——Kojo称之为多分支探索。
Right now, each agent largely works in isolation on a task you give it. But the future could see scenarios where multiple agents with different specialties collaborate. One agent might be great at frontend tasks and another at backend tasks, and you give them a coordinated task (or maybe they even figure out how to split it). Alternatively, an agent could explore multiple solution paths in parallel—what Kojo calls multibranch exploration.
想象一下,你给人工智能一个复杂的问题,它能生成三个采用不同方法或架构的子任务,然后选择最佳方案——甚至还会询问你更倾向于哪个方向。这可以大幅缩短评估不同实现方案所需的时间(目前这可能需要多名工程师花费数天时间进行原型设计)。当然,协调这项工作并非易事,但随着智能体框架的不断发展,这并非遥不可及。
Imagine you give a complex problem to an AI and it spins up three subtasks with different approaches or architectures, then chooses the best one—or even asks you which direction you prefer. This could dramatically reduce the time it takes to evaluate different implementations (something that currently might take multiple engineers prototyping over days). Of course, orchestrating that is a nontrivial task, but it’s not out of the question as agent frameworks become more advanced.
未来的智能体或许足够智能,能够在决策点主动寻求指导。这并非空穴来风:目前已有针对学习型智能体(LLM)的不确定性估计和自我反思方面的积极研究,初步迹象表明,模型可以通过训练或引导来识别自身不确定之处并寻求帮助,而不是贸然行事。例如,智能体可能会遇到可以使用两个库来实现某个功能的情况,此时它不会盲目猜测,而是会停下来(就像初级开发人员那样)询问:
Future agents may be smart enough to ask for guidance proactively at decision points. This isn’t just speculation: there’s active research happening on uncertainty estimation and self-reflection for LLMs, with early signs that models can be trained or prompted to recognize when they’re unsure and ask for help rather than forge ahead. For example, an agent might reach a point where two libraries could be used to implement something and instead of guessing, it pauses (much like a junior dev might) and asks you:
我可以用库 A 或库 B 来做这件事——你有什么偏好吗?
I could use Library A or B for this—do you have a preference?
业内越来越多的人认为,添加这种“智能检查点”机制能让智能体更值得信赖,更像是合作者而非黑箱。这与人类团队协作的方式也十分契合——懂得何时提问而非虚张声势。虽然目前还处于早期阶段,但我们开始看到越来越多的模型通过工具使用反思、基于不确定性阈值的规划以及在运行过程中明确提供用户反馈等技术来支持这种行为。智能检查点机制要求智能体了解自身的不确定性,这本身就是一个挑战,但研究人员正在努力提升人工智能的自我意识,包括其对自身不确定性的感知能力。
There’s a growing belief in the industry that adding this kind of “intelligent checkpointing” makes agents feel more trustworthy, like collaborators rather than black boxes. It also aligns well with how humans work in teams—knowing when to ask instead of bluffing. While it’s still early, we’re starting to see more models that support this kind of behavior through techniques like tool-use reflection, planning with uncertainty thresholds, and making explicit affordances for user feedback midrun. Intelligent checkpointing requires the agent to know its own uncertainty, which is a challenge, but researchers are working on AI self-awareness, including confidence.
随着我们将越来越多的工作分配给客服人员,我们需要更好的方法来跟踪他们的工作进度。Kojo 提出了一个客服人员收件箱——一个统一的视图,显示客服人员正在处理的任务、已完成的任务以及需要您关注的任务。这可以是一个仪表盘,显示所有正在进行的客服人员任务及其进度(例如“已完成 3/5 个步骤”或“等待审核”)和结果。
As we offload more work to agents, we’ll need better ways to keep track of what they’re doing. Kojo proposes an agent inbox—a unified view of what tasks agents are working on, what’s been done, and what needs your attention. This could be a dashboard showing all running agent tasks along with their progress (“3/5 steps completed” or “awaiting review”) and results.
未来将不再使用目前日志和 PR 混杂的界面,取而代之的是一个清晰的代理管理界面。或许 IDE 会新增一个“代理”侧边栏,列出活跃任务和更新信息。用户可能还会收到通知:
代理人 X 已完成任务 Y 并提交了 PR #123。
Z 特工需要输入信息才能继续。
这一基础设施对于在不失全局掌控的情况下扩展使用规模至关重要。毕竟,谁也不希望看到10个静默的机器人毫无章法地运行,而没有任何中央控制。
Instead of the current mix of logs and PRs, a clear interface to manage agents will emerge. Perhaps IDEs will have an “Agents” sidebar listing active tasks and a feed of updates. You might also get notifications:
Agent X has finished task Y and opened PR #123.
Agent Z needs input to continue.
This infrastructure will be important to scaling up usage without losing overview. After all, no one wants 10 silent bots doing who knows what with no central control.
我预见到一个更紧密的闭环,在这个闭环中,问题跟踪系统(Jira、GitHub Issues、Linear)中的问题可以由代理从头到尾解决。事实上,CodeGen 的 Linear 集成已经暗示了这一点。
工作流程可能如下:
项目经理提交了一份包含规格说明的工单。
开发人员(或技术主管)批准其用于人工智能。
AI代理会获取该请求,执行该请求,并将PR附加到工单上。
人工审核并测试修复方案后,关闭工单。
这可以使开发过程更加连续。类似地,持续集成 (CI) 系统可以在某些检查失败时自动调用代理。例如,如果安全扫描发现漏洞,代理可以尝试升级存在漏洞的库或重构风险代码,然后提交包含修复的拉取请求 (PR)。或者,如果 PR 提交后代码覆盖率低于阈值,代理可以生成额外的测试来提高覆盖率。可以将其视为自动化维护。
I foresee a tighter loop where an issue in your tracker (Jira, GitHub Issues, Linear) can be addressed by an agent from end to end. In fact, CodeGen’s Linear integration already hints at this.
The workflow might be as follows:
A PM files a ticket with specs.
A developer (or tech lead) approves it for AI.
An AI agent picks it up, does it, and attaches the PR to the ticket.
A human reviews and tests the fix and closes the ticket.
This could make the development process more continuous. Similarly, CI systems might invoke agents automatically when certain checks fail. For instance, if a security scan finds vulnerabilities, an agent could attempt to upgrade the vulnerable library or refactor the risky code and then open a PR with the fix. Or if code coverage drops below threshold after a PR, an agent could generate additional tests to raise it. Think of it as automated maintenance.
举个具体的例子,Dependabot 目前会提交 PR 来更新依赖项。人工智能代理不仅可以提交 PR,还可以调整因更新而导致的任何代码错误,运行测试,并确保一切正常——基本上就是一个功能更强大的 Dependabot。
As a concrete example, Dependabot currently opens PRs to update dependencies. Not only could an AI agent open the PR, but it could also adjust any code that broke due to the update, run tests, and ensure it’s all good—basically a supercharged Dependabot.
主要人工智能模型本身(例如 GPT-4、Gemini、Claude 等)会不断提升其代码理解和生成能力。随着模型能力的增强,那“最后 30%”的差距可能会缩小。我们或许会看到一些智能体几乎不会错过明显的代码重用或极端情况,因为这些模型已经接受过更多场景的训练,或者拥有更优秀的推理能力。
The major AI models themselves (GPT-4, Gemini, Claude, and the like) will continue to improve their code understanding and generation. As they get more capable, that “last 30%” gap might shrink. We might see agents that hardly ever miss an obvious reuse or edge case, because the model has been trained on even more scenarios or has better reasoning.
有了更优秀的模型,智能体犯的错误会更少,需要的监督也会更少,而且可能还能处理更复杂的任务。话虽如此,软件本身就很复杂,所以我认为总会有一些环节需要人类的判断。也许这部分工作会从最后的30%变成最后的5%到10%。
With better models, agents will make fewer mistakes, require less oversight, and possibly handle more complex tasks. That said, software is inherently complex, so I suspect there will always be some gap for human judgment. Maybe it becomes the last 5%–10% rather than the last 30%.
我还预计模型效率会越来越高,从而使那些担心数据隐私(或成本)的用户能够运行本地或自托管代理。开源代码模型或许也能迎头赶上,最终实现本地部署的代理在许多任务上几乎与大型云代理一样出色。
I also expect models to become more efficient, making it feasible for those worried about data privacy (or cost) to run local or self-hosted agents. Open source coding models might catch up, to the point where you can have an on-prem agent that’s nearly as good for many tasks as the big cloud agents.
我们可能会看到针对不同领域或角色的专用编码代理。例如,想象一下“BugFixer”代理,你只需指向失败的测试或错误日志,它就能精准定位错误;“PerformanceGuru”代理专注于分析和优化性能瓶颈;或者一个专门用于从现有代码库中编写文档和代码注释的代理。
We might see specialized coding agents for different domains or roles. Imagine a “BugFixer” agent that you point at a failing test or error log and it zeroes in on the bug, a “PerformanceGuru” agent that focuses on profiling and optimizing hot spots, or a specialized agent for writing documentation and code comments from an existing codebase.
通过专业化,智能体可以整合更多特定领域的知识或工具。例如,我们可能会看到一个与游戏引擎集成以协助游戏开发任务的智能体,或者一个擅长数据工程管道的智能体。一支由特定领域人工智能专家组成的团队可以类似于人类团队内部的专业知识分布,例如一些开发人员擅长前端工作,而另一些则擅长基础设施。你可以拥有像 DocsBot、TestBot、RefactorBot 和 SecurityBot 这样的人工智能队友,每个机器人都针对特定用途进行了优化。事实上,Cursor 已经推出了名为 BugBot 的工具,用于自动审查 PR,这正是朝着这个方向迈出的一步。BugBot 不编写代码;它会对 PR 进行注释,重点关注 bug 风险,就像一个功能强大的静态分析工具。
By specializing, agents could incorporate more domain-specific knowledge or tools. We might see an agent that integrates with game engines to help with game dev tasks, or one that’s great at data-engineering pipelines. A team of narrow AI specialists could parallel the distribution of expertise within human teams, where some devs are known for frontend work and others for infrastructure. You could have AI teammates like DocsBot, TestBot, RefactorBot, and SecurityBot, each tuned for those purposes. In fact, Cursor already has something called BugBot for automated PR reviews, which is a step in that direction. BugBot doesn’t write code; it comments on PRs with a focus on bug risks, like a static analysis on steroids.
如果代理处理更多常规编码工作,开发人员的技能组合将更多地转向设计、架构和监督,正如第四章所述。软技能,例如清晰地传达需求(无论是对人类还是对人工智能)变得更加重要。代码阅读和审查技能很可能变得与代码编写技能同等重要。我们或许也应该更加重视测试:由于测试是验证人工智能输出的关键手段,因此,擅长编写测试用例(或指导人工智能编写测试用例)仍然具有价值。
本质上,“人类30%”将专注于软件开发中更高层次的批判性思维和质量控制方面。我预计初级开发人员的成长方式也会发生变化。他们或许会先从管理人工智能代理完成简单任务入手,然后再编写大量代码,这既有利(他们可以快速交付价值),也具有挑战性(他们需要学习基础知识,而不是把人工智能当作拐杖)。对于那些愿意适应的人来说,这是一个激动人心的时代,但对于那些更喜欢传统方式的人来说,可能会感到不适。正如我在第四章中提到的,在这个人工智能时代,要想让你的职业生涯“面向未来”,关键在于拥抱这些工具,并发挥你独特的人类优势。
If agents handle more routine coding, the skill sets of developers will shift more toward design, architecture, and oversight, as discussed in Chapter 4. Soft skills, like clearly communicating requirements (to humans and AIs alike), become even more important. Code reading and review skills may well become as essential as code writing skills. We might also place more emphasis on testing: since tests are a critical way to verify AI outputs, being good at writing test cases (or guiding AI to write them) remains valuable.
Essentially, the “human 30%” will concentrate on the higher-level critical thinking and quality-control aspects of software development. I suspect we’ll also see changes in how junior developers ramp up. Maybe they’ll start by managing an AI agent on simple tasks before writing a ton of code themselves, which could be both good (they can deliver value quickly) and challenging (they need to learn the fundamentals and not treat the AI as a crutch). It’s an exciting time for those willing to adapt, but it may be uncomfortable for those who prefer the old ways. As I noted in Chapter 4, a big part of “future-proofing” your career in this AI era is embracing these tools and emphasizing your uniquely human strengths.
我们可能会看到工程团队中出现诸如“AI 管理员”或“自动化主管”之类的角色——这些人……他们尤其擅长利用人工智能代理、围绕它们设计工作流程以及维护其配置。这类似于构建系统变得复杂时出现的“构建/发布工程师”,或者基础设施自动化发展时出现的“DevOps工程师”。同样,检查人工智能是否引入任何不安全模式的审计可能会成为代码审查的标准流程。
We might see the rise of roles like “AI Wrangler” or “Automation Lead” in engineering teams—people who are particularly skilled at leveraging AI agents, designing workflows around them, and maintaining their configurations. It’s analogous to how “build/release engineers” emerged when build systems became complex, or “DevOps engineers” as infrastructure automation grew. Similarly, audits to check that AI has not introduced any insecure patterns might become standard in code reviews.
为了增强信心,可能会更加重视测试文化:或许每个智能体 PR 都必须包含测试用例(由智能体或人类编写)才能被考虑合并。如果 AI 智能体编写了大量代码,那么或许应该由人类工程师编写更多测试用例(反之亦然),以确保独立验证。
There may be more emphasis on testing culture to provide extra confidence: perhaps every agent PR will have to include tests (written by the agent or a human) to be considered for merge. If AI agents are writing a lot of the code, maybe human engineers should write more of the tests (or vice versa) to ensure independent verification.
本质上,未来有了后台编码代理,开发者只需负责编排和验证,而人工智能代理则负责执行和实现(见图11-1)。软件工程的重点将更多地放在管理自动化编码团队上,而不是手动完成每一步操作。这将极大地提升生产力,减少繁琐的底层工作,甚至让团队有时间处理以前无暇顾及的技术债务和维护任务。(想象一下,现在只需让人工智能处理所有细小的错误和不一致之处,就能轻松解决!)它还有助于降低新想法原型设计的门槛:你可以让人工智能绘制完整的应用程序原型,然后自己进行微调。由于人工智能能够快速生成备选方案,我们或许还能在最终决策前探索更多解决方案。
In essence, the future with background coding agents looks like one where developers orchestrate and verify, while AI agents execute and implement (see Figure 11-1). Software engineering could become more about supervising a fleet of automated coders and less about doing every step manually. This could unlock massive productivity, reduce the boring grunt work, and even allow teams to tackle technical debt and maintenance tasks they never had time for before. (Imagine clearing out all those minor bugs and inconsistencies because now you can just tell an AI to handle them!) It might also lower the barrier to prototyping new ideas: you could have an AI draft a whole prototype app, then just fine-tune it yourself. We may also get to explore more solutions before settling on decisions, since AI can generate alternatives quickly.
然而,我们的行业必须谨慎地整合这些变革。人的因素——包括创造力、直觉和道德判断——仍然是不可替代的。人工智能可以增强我们的能力,但如果不加以控制,它也会放大错误。
However, our industry must integrate these changes carefully. The human element—with its creativity, intuition, and ethical judgment—remains irreplaceable. AI can amplify our abilities, but it can also amplify mistakes if unchecked.
我的愿景是乐观的:如果运用得当,自主编码代理将提高开发人员的效率,使我们能够专注于构建软件过程中真正具有挑战性和趣味性的部分,最终帮助我们更快地构建出更优质的软件。要实现这一目标,我们需要培养良好的实践经验,并意识到我们作为开发人员和工程师的角色正在不断演变。
My vision is optimistic: used wisely, autonomous coding agents will make developers more productive and allow us to focus on the truly challenging and interesting parts of building software, ultimately leading us to build better software faster. Achieving that means cultivating good practices and being aware that our role as developers and engineers is evolving.
关于 Vibe 编码的未来,最引人入胜的问题之一是它将如何塑造编程语言。如果我们只需“告诉人工智能我们想要什么”,我们还需要传统的语法和语言吗?英语(或任何人类语言)会成为新的编程语言吗?本节将探讨这些可能性。
One of the most intriguing questions about the future of vibe coding is how it will shape programming languages. If we can “just tell the AI what we want,” will we even need traditional syntax and languages? Will English (or any human language) become the new programming language? This section explores the possibilities.
我们已经看到一些工具开始以自然语言作为代码运行,用户只需用自然语言描述任务,人工智能就能自动生成代码。如果这种趋势持续下去,我们或许可以将更多的编程精力从实现代码转移到明确意图和需求上。未来的开发环境或许允许开发者(甚至非开发者)编写类似这样的代码:
We’ve already seen signs of natural language functioning as code in tools where you describe a task in plain language and the AI writes the code. If this trend continues, we might shift more of the programming effort to specifying the intent and requirements rather than the implementation. Future development environments could allow developers (or even nondevelopers) to write something like this:
每小时检查数据库中是否存在不活跃用户,并使用模板 X 向 90 天未登录的用户发送电子邮件提醒。如果电子邮件被退回,则在数据库中将该用户标记为“无效电子邮件”。
Every hour, check our database for inactive users, and send an email reminder to any user who hasn’t logged in for 90 days, using template X. If the email bounces, mark the user as ‘invalid email’ in the database.
人工智能可以接收这份规范并将其转化为相应的代码(例如设置定时任务或计划函数、编写 SQL 查询或使用 ORM,或者调用邮件 API)。本质上,程序员的角色更多地转向了策略和行为的描述。
The AI could take this specification and translate it into the appropriate code (like setting up a cron job or scheduled function, writing the SQL queries or using the ORM, or calling an email API). Essentially, the programmer’s role becomes more about policy and behavior description.
这并不意味着编程语言会在一夜之间消失。相反,可能会出现一种分层结构:使用自然语言进行高级编排,并在底层使用现有的编程语言进行细粒度控制。
This doesn’t mean programming languages will vanish overnight. Instead, what might happen is a layering: natural language for high-level orchestration and existing programming languages under the hood for fine-grained control.
编程语言存在的原因之一是自然语言可能存在歧义。如果我们完全摒弃形式语言,就可能与机器沟通不畅。人工智能或许可以通过上下文消除歧义并提出澄清问题来弥合这种鸿沟,但这很可能存在局限性;某些复杂的算法或优化仍然需要非常具体的指令,而这些指令用代码表达比用文字表达更容易。因此,未来的程序员或许需要在某种意义上成为“双语者”:既要精通人类语言以便与人工智能交流,又要精通底层技术概念以便验证和调整人工智能的生成结果。
One reason programming languages exist is because natural language can be ambiguous. If we remove formal languages entirely, we risk miscommunicating with the machine. AI might bridge this gap by disambiguating based on context and by asking clarifying questions, but there’s likely a limit; certain complex algorithms or optimizations might still require very specific instructions that are easier to convey in code than prose. Thus, it’s conceivable that programmers of the future will need to be bilingual in a sense: fluent in human language to talk to the AI, and fluent in the underlying technical concepts to verify and tweak what the AI produces.
我们或许还可以看到特定领域的自然语言的兴起——人工智能可以可靠地理解的英语(或其他语言)的受限形式,专为软件领域量身定制:例如,用于编写人工智能可以转换为测试或代码的用例的“需求语言”。
We might also see the rise of domain-specific natural languages—constrained forms of English (or other languages) that AIs can reliably understand, tailored to software domains: for example, a “requirements language” for writing use cases that the AI can convert into tests or code.
即使人工智能无法完全实现自然语言,它的影响也极有可能将编程语言推向更高的抽象层次。过去,我们从汇编语言发展到高级语言,从手动内存管理发展到垃圾回收机制,每一次都提升了抽象层次。人工智能或许能够让我们即时定义抽象概念。正如本书中讨论的“意图编程”:你设定一个目标,人工智能会想办法实现它,必要时还会编写一些底层代码。
Even if they don’t go all the way to full natural language, AI’s influence will likely bring programming languages to higher levels of abstraction. In the past, we moved from assembly to high-level languages and from manual memory management to garbage-collected environments, each time raising the level of abstraction. AI could allow us to define abstractions on the fly. Think of this in terms of “programming with intent,” as discussed throughout this book: you specify a goal and the AI figures out how to achieve it, possibly writing lower-level code as needed.
另一种可能性是融合自然语言和代码的混合语言。例如,未来的语言可能允许编写如下代码:
Another possibility is hybrid languages that blend natural language and code. For example, a future language might allow code like this:
// 根据订单创建客户姓名列表,排除重复项
//并按字母顺序排序,然后打印出来。
list<Customer> customers = orders -> map(order -> order.customerName)
-> unique()
-> 排序()
-> print();// Create a list of customer names from the orders, excluding duplicates
// and sorted alphabetically, then print it.
list<Customer> customers = orders -> map(order -> order.customerName)
-> unique()
-> sort()
-> print();
在这个伪示例中,人工智能几乎可以执行英文注释。或许在实际环境中,甚至不需要 lambda 表达式语法;人工智能可以从注释中推断出你的意图并自动补全。或者,这种语言可能包含一些看起来像英语但又足够正式的结构,以便人工智能能够解析。你可以把它想象成注释和伪代码向实际代码的演变,而人工智能则负责解读注释和伪代码背后的意图。
In this pseudo example, the comment in English is almost executable by the AI. Maybe, in the actual environment, you wouldn’t even need the lambda syntax; the AI could infer from the comment what you intend and fill it out. Or maybe the language would have constructs that look like English but are formal enough for the AI to parse. Think of it as an evolution of comments and pseudocode into actual code, with AI interpreting the intent behind them.
编程正变得越来越像对话。你不再需要编写完整的程序,而是与人工智能展开对话:
Coding is already becoming more conversational. Instead of writing a complete program, you start a dialogue with the AI:
提示: “我需要一个函数,根据客户的购买历史记录计算其忠诚度积分。”
AI: “当然可以。所有产品的积分都一样吗?还是有些产品积分更高?时间因素又该如何考虑(例如,最近购买的商品与较早购买的商品)?”
提示: “电子产品可获得其他类别2倍积分。上个月的购买还可获得10%的额外积分。”
AI: “明白了。这是实现该功能的函数…… [AI 展示代码]。我是否还需要为不同的场景生成测试?”
提示: “是的,还要确保它能妥善处理没有购买记录的情况(应该返回 0 分)。”
Prompt: “I need a function to calculate loyalty points for customers based on their purchase history.”
AI: “Sure. Do all products count equally, or do some products give more points? And how should time factor in (e.g., recent purchases versus older)?”
Prompt: “Electronics give 2x points compared to other categories. And purchases in the last month give a 10% bonus.”
AI: “Understood. Here is the function implementing that… [AI presents code]. Shall I also generate tests for different scenarios?”
Prompt: “Yes, and also make sure it handles the case of no purchase history gracefully (should return 0 points).”
在这种情况下,编程变成了与人工智能进行自然语言的互动,人工智能负责编写代码并提出澄清问题。这类似于结对编程,只不过结对伙伴是人工智能。我们已经看到了早期版本,例如 ChatGPT 插件和 Copilot Chat 等。未来,这可能成为软件开发的主流模式:通过对话逐步完善软件,这比从头开始编写静态文本文件要灵活得多。
In this scenario, programming is a back-and-forth in natural language with the AI, which writes the code and asks clarification questions. This is akin to pair programming, except the pair partner is an AI. We already see early versions with ChatGPT plug-ins and Copilot Chat, etc. In the future, this could become the dominant mode for creating software: a conversation that progressively refines the software, which is much more fluid than writing a strict static text file from scratch.
即使大部分编程工作都转向自然语言,理解代码和计算机的工作原理仍然至关重要。计算器和电子表格并没有取代数学家或会计师对算术的理解。你需要知道人工智能的输出何时出现偏差。如果人工智能误解了英文指令,经验丰富的开发人员可能会切换到伪代码或实际代码来找出问题所在。因此,尽管语法细节可能变得不再那么重要(如果人工智能可以自动填充,就无需记住某些API参数的确切顺序),但算法思维和调试能力仍然至关重要。编程语言可能会改变,但其背后的逻辑和问题解决能力却始终存在。
Even if much of coding becomes natural language–driven, understanding how code and computers work will remain important. Calculators and spreadsheets didn’t eliminate the need for a mathematician or accountant to understand arithmetic. You need to know when the AI’s output is off somehow. If the AI misunderstands an English instruction, a skilled developer might switch to pseudocode or actual code to pin it down. So while the trivia of syntax might become less crucial (no need to remember the exact order of some API’s parameters if the AI can fill that in), algorithmic thinking and debugging will still be vital. The languages might change, but the underlying logic and problem-solving skills persist.
然而,编程的入门门槛已经降低。非开发人员和领域专家可以通过与人工智能进行交互,利用“Vibe Code”直接创建简单的应用程序。这种民主化令人振奋:更多的人无需深厚的编程知识即可创建软件解决方案。专业的开发人员随后将着手解决更复杂的问题,安全地集成这些由用户开发的脚本,或构建支持此类交互的平台。
However, the barrier to entry for programming is already lower. Nondevelopers and domain experts can directly create simple applications by conversing with AI through vibe coding. This democratization is exciting: more people can create software solutions without deep programming knowledge. The professional developers will then tackle the harder problems, integrate those citizen-developed scripts safely, or build the platforms that allow such interactions.
即使人工智能帮助我们用自然语言编写代码,人工智能本身也可能发展出介于两者之间的新“语言”。或许会出现一些本质上对人工智能友好的新型编程范式——这意味着它们会为人工智能填补空白留出空间,例如,一种允许使用占位符编写部分程序的语言,人工智能可以解析这些占位符(例如,“[在此处优化速度]”),或者允许使用模糊逻辑,人工智能可以将这些模糊逻辑细化为确定性逻辑。
Even as AI helps us code in natural language, AIs themselves might evolve new “languages” that are somewhere in between. Perhaps new programming paradigms will emerge that are inherently AI-friendly—meaning they leave space for the AI to fill in blanks, for instance, a language that allows partial programs with placeholders that an AI can resolve (“[Optimize here for speed]”) or with fuzzy logic that the AI can refine into deterministic logic.
最终,编程语言不太可能被英语完全取代,而是二者融合:开发者将拥有更强大的表达能力,而告诉计算机该做什么的方式也将更加直观。正如Andrej Karpathy 精辟地指出:“也许编程的未来不再是编写完美的代码,而是完美地解释你的需求。” 编程的本质——清晰地思考问题并明确解决方案——依然存在。然而,规范的形式将变得更加自然,人工智能将作为翻译器,把我们高层次的意图转化为低层次的执行。
In the end, what’s likely is not a complete replacement of programming languages with English but a fusion of the two: more expressive power for developers and a more intuitive way to tell computers what to do. As Andrej Karpathy aptly puts it, “Maybe the future of programming isn’t about writing perfect code anymore. Maybe it’s about perfectly explaining what you want.” The essence of programming—thinking clearly about a problem and specifying a solution—remains. The form of the specification, however, will evolve to be more natural, with AI as the translator that turns our high-level intentions into low-level execution.
未来充满无限可能:更快的开发速度、更高的可访问性,以及能够专注于我们想要实现的目标,而不是纠结于如何编写代码的细节,从而创建日益复杂的系统。一如既往,抽象的每一次飞跃都带来了创造力的爆发(高级语言使得汇编语言无法扩展的软件成为可能)。自然语言驱动的开发可能会掀起新一轮创新浪潮,而“vibe coders”(一种语言编程者)将站在最前沿,通过软件创造全新的世界。
This future holds great promise: faster development, more accessibility, and the ability to create increasingly complex systems by focusing on what we want to achieve rather than the nitty-gritty of how to type it out. As always, each leap in abstraction has led to an explosion in creativity (high-level languages enabled software that assembly could never have scaled to). Natural-language-driven development could unleash another wave of innovation, with vibe coders at the forefront, literally talking new worlds into existence through software.
Throughout this book, several fundamental principles and ideas have emerged:
氛围编码转变这种转变的重点不再是编写循序渐进的代码,而是表达意图或期望的结果,并让AI处理实现细节。这改变了我们解决问题的方式:我们更多地思考想要实现的目标,而不是如何编写代码。这是一种更高层次的软件开发思维方式。
Vibe coding shifts the focus from writing step-by-step code to expressing the intent or desired outcome and letting AI handle the implementation details. This changes how we approach problems: we think more about what we want to achieve and less about how to type it out. It’s a higher-level way of thinking about software development.
而不是在Vibe Codeing中,人工智能单独使用时就像一个结对程序员或助手,它具有交互性和迭代性。我们看到,引导人工智能(通过提示工程)、审查其输出以及将我们的优势与人工智能的优势相结合至关重要。未来并非“人工智能取代程序员”,而是程序员与人工智能协同工作,从而提高生产力。
Rather than a tool used in isolation, AI in vibe coding is like a pair programmer or an assistant. It’s interactive and iterative. We saw how important it is to guide the AI (through prompt engineering), to review its output, and to combine our strengths with the AI’s. The future isn’t “AI replacing programmers” but programmers working alongside AI for greater productivity.
我们强调,非常棒人工智能的力量伴随着巨大的责任。减少偏见、确保公平、保持流程透明以及维护问责制都至关重要。业界已经意识到,在缺乏监管的情况下依赖人工智能可能会引发问题,因此,围绕测试人工智能输出、记录人工智能参与情况以及解决法律问题(例如人工智能生成代码的知识产权)的最佳实践正逐渐成为标准流程的一部分。
We emphasized that with great power (of AI) comes great responsibility. Mitigating bias, ensuring fairness, keeping processes transparent, and maintaining accountability are all critical. The industry is recognizing that relying on AI without guardrails can cause issues, so best practices around testing AI outputs, documenting AI involvement, and addressing legal questions (like IP rights of AI-generated code) are becoming part of standard procedure.
人工智能的作用人工智能的应用范围涵盖测试、调试、设计、项目管理等诸多方面。这种全方位的集成意味着整个软件生命周期都将因人工智能而加速和增强。各种工具将越来越多地支持这些阶段——有些工具已经具备这种功能,例如集成开发环境(IDE)中的人工智能测试生成功能或基于人工智能的项目进度安排工具。
AI’s role extends to testing, debugging, design, project management, and more. This holistic integration means the entire software lifecycle is accelerated and enhanced by AI. Tools will increasingly support these phases—some already do, like AI test generation in IDEs or AI-based project scheduling tools.
程序员践行上述实践,你会发现自己的技能组合正在不断发展——除了传统的编码和算法技能外,还包括快速工程、人工智能监管、数据分析和高级设计。核心问题解决思维仍然至关重要,但日常工作内容已有所不同。
Programmers who embrace the previously mentioned practices will find that their skill set is evolving—shifting to include prompt engineering, AI oversight, data analysis, and high-level design alongside traditional coding and algorithmic skills. The core problem-solving mindset remains crucial, but the day-to-day tasks look different.
然而,某些基本原则依然不变:深入理解问题领域,编写清晰的规范(提示信息本质上就是规范),坚持严格的测试和验证,以及关注用户需求。人工智能并不会改变这些原则;恰恰相反,它反而会放大这些原则的重要性,因为任何模糊不清或缺乏清晰度的地方都会被人工智能的超快执行速度放大。
Yet certain fundamentals hold: understanding your problem domain deeply, writing clear specifications (prompts are basically specs), maintaining rigorous testing and validation, and focusing on user needs. AI doesn’t change these; if anything, it amplifies their importance because any ambiguity or lack of clarity can be magnified by AI’s ultrafast execution.
这种全新的“氛围编码”范式正在以切实的方式重塑整个行业。采用人工智能工具的团队报告称,生产力显著提升:开发人员可以在更短的时间内完成功能,或者用同样的资源处理更复杂的项目。它也降低了准入门槛:经验不足的开发人员可以在人工智能的指导下取得更大的成就,并有可能更快地提升自身水平。另一方面,它也促使经验丰富的开发人员拓展视野,避免固守旧的工作流程。
This new paradigm of vibe coding is reshaping the industry in practical ways. Teams that adopt AI tools report significant boosts in productivity: developers can complete features in less time, or handle more complex projects with the same resources. It’s also lowering entry barriers: less-experienced developers can achieve more with AI guidance, potentially leveling up faster. On the flip side, it’s pushing experienced devs to expand their horizons and avoid getting complacent with old workflows.
企业招聘时不仅注重编程知识,也开始关注“人工智能素养”——即有效利用人工智能工具的能力。未来的职位描述可能很快就会包含对人工智能编码助手的熟悉程度,就像如今对版本控制或云平台的熟悉程度一样。因此,成为Vibe编码领域的先行者将带来职业优势。
Companies are starting to hire not just for programming knowledge but also for “AI literacy”—the ability to leverage AI tools effectively. Job descriptions might soon include familiarity with AI coding assistants, just like they include familiarity with version control or cloud platforms today. Being a pioneer in vibe coding thus offers a career advantage.
重要的是,Vibe 编码在一定程度上实现了编程的民主化。更多的人——包括那些并非传统软件工程师的人——可以通过描述他们的需求来参与软件创建。这可能会促进针对特定需求的定制软件的蓬勃发展,这些软件由领域专家在人工智能的帮助下创建(而专业开发人员则专注于为他们提供安全保障、平台和完善的核心组件)。
Importantly, vibe coding democratizes programming to an extent. More people—including those who aren’t traditional software engineers—can participate in software creation by describing what they want. This could lead to a flourishing of software tailored to niche needs, created by domain experts with the help of AI (with professional developers focusing on providing guardrails, platforms, and polished core components for them to use).
这是一个令人振奋的时代。我们正站在变革的边缘,而作为开发者的我们,将有机会塑造这场变革。回想计算机发展的早期阶段:那些拥抱个人电脑革命的人最终创造了我们今天所处的世界。如今,人工智能在编程领域也正处于类似的转折点。拥抱它意味着参与定义未来几十年软件的构建方式。
It’s an inspirational time. We stand on the brink of a transformation that we as developers get to shape. Think back to the early days of computing: those who embraced the personal computer revolution ended up creating the world we have now. Today, AI in programming is a similar inflection point. Embracing it means being part of defining how software is built for decades to come.
编程的未来不是自然而然降临到我们身上的,而是我们自己创造的。开发者社区的每一位成员都对Vibe编码和人工智能工具的采纳、监管和发展负有责任。这是对各位读者和实践者的行动号召:
The future of programming is not something that will just happen to us—it’s something we will create. Each of us in the developer community has a role to play in how vibe coding and AI tools are adopted, regulated, and advanced. This is a call to action for you as a reader and practitioner:
不要坐等所有答案都摆在你面前。走出舒适区,在不同的情境中尝试“感觉编码”。利用人工智能创造一些新奇独特的东西。突破这些工具的极限。或许你会发现一些全新的应用场景,或者一些尚未被记录的局限性。每一次实验,无论成功还是失败,都会为社区贡献知识。
Don’t wait for all the answers to be given to you. Go out and try vibe coding in different contexts. Use AI to build something quirky and new. Push the boundaries of what these tools can do. Maybe you’ll discover a novel use case or a limitation that no one has documented yet. Each experiment, whether it succeeds or fails, contributes knowledge to the community.
写下你的经验,或者至少与同行讨论。如果你发现了一种非常有效的技巧,请分享出来。如果你遇到了陷阱,请提醒他人。在这个快速发展的时代,社区知识共享是我们所有人保持进步的方式。你可以分享你找到的解决人工智能问题的方案,从而为他人节省数天的调试时间;或者分享一个很棒的人工智能辅助项目,激发他人的创造力。
Write about your experiences or at least discuss them with peers. If you find a technique that works brilliantly, publish it. If you encounter a pitfall, warn others. In this rapid evolution, community knowledge sharing is how we all keep up. You could save someone days of debugging by posting that solution you found to an AI quirk, or spark someone’s creativity by sharing a cool AI-assisted project.
如果你有兴趣,不妨参与到人工智能工具的开发中来。这可能意味着为开源人工智能框架贡献代码,或者仅仅是向工具开发者提供详细的反馈(他们中的许多人都非常渴望听到用户关于改进的建议)。通过帮助塑造这些工具,你可以直接影响它们的未来发展方向。如今许多人工智能编码助手之所以能够取得如此巨大的进步,正是因为像你这样的开发者测试了测试版并提供了宝贵的意见。
If you have the inclination, contribute to the development of AI tools themselves. This might mean contributing code to open source AI frameworks or simply giving detailed feedback to tool makers (many of whom are very eager to hear from users about what to improve). By helping shape the tools, you directly influence how the future will look. Many AI coding assistants today have come a long way because developers like you tested beta versions and provided insight.
在您的组织或社区中,倡导使用人工智能来提高生产力,并培训员工正确使用人工智能。鼓励管理者预留时间学习人工智能工具,或更新可能因误解而禁止使用人工智能的政策。展示如何安全有效地使用人工智能。人工智能增强团队效率的成功案例越多,整个行业就越会积极拥抱这项技术。
Within your organizations or communities, advocate for using AI to improve productivity and also for training people to use it properly. Encourage managers to allow time for learning AI tools or to update policies that might forbid them out of misunderstanding. Show how it can be done securely and beneficially. The more success stories emerge of AI augmenting teams positively, the more the industry will lean into it.
在这个新时代,我们都要保持学生的心态。保持谦逊和开放的心态。未来的后辈可能天生就精通人工智能工具(就像今天的应届毕业生可能比一些老前辈从小就接触到更多的编程知识一样)。无论经验水平如何,都要做好向任何人学习的准备,因为这对每个人来说都是全新的领域。如果你始终保持这种学习的心态,你就能不断进步,避免陷入自以为是的陷阱。
Adopt the mindset that we are all students in this new era. Stay humble and open-minded. The juniors of tomorrow might come in knowing AI tooling natively (like how today’s new grads might have grown up with more exposure to coding than some older folks did). Be ready to learn from anyone, regardless of experience level, because this is new to everyone in some way. If you keep that student mentality, you’ll always find growth and avoid the trap of thinking you’ve figured it all out.
对各种可能性充满热情——你的热情会激励他人。但必要时也要保持谨慎,确保热情不会导致鲁莽使用。例如,倡导人工智能驱动的开发,但也要推动对人工智能输出进行单元测试和代码审查。这种平衡的方法将使“vibe coding”(一种基于直觉的编码方式)得以持续发展并受到尊重。
Be enthusiastic about what’s possible—your excitement will inspire others. But also be the voice of prudence when needed, ensuring that excitement doesn’t lead to careless use. For example, champion AI-driven development but also push for unit tests and code reviews on AI outputs. This balanced approach will make vibe coding sustainable and respected.
随着你技艺的精进,要乐于帮助新手。Vibe 编码降低了入门门槛,这意味着更多初学者可以投身编程。他们需要指导来学习扎实的基础知识,而这些基础知识可能会被人工智能抽象化。通过指导他们,你可以确保下一代开发者不会在缺乏理解的情况下过度依赖人工智能。你将传承优秀的软件工程实践,而人工智能则进一步增强了这些实践。
As you gain mastery, help newcomers. Vibe coding lowers the barriers to entry, meaning more beginners might dive into programming. They’ll need guidance to learn solid fundamentals that AI might abstract away. By mentoring them, you ensure that the next generation of developers doesn’t become overly reliant on AI without understanding. You’ll be passing on the torch of good software engineering practices, now enhanced by AI.
我们正经历着指数级的变革,这是一个千载难逢的机遇。想想以往的技术飞跃,从工业革命到互联网的蓬勃发展——那些参与其中的人塑造了整个行业。如今,人工智能在软件开发领域也正处于这样一个关键时刻。这不仅仅关乎保住工作或让工作更轻松;更关乎你是否能够参与技术的发展方向及其对社会的影响。
The exponential change we’re seeing is a rare opportunity. Think of previous technological leaps, from the Industrial Revolution to the internet boom—those who engaged with them shaped entire industries. We are at such a juncture with AI in software development. It’s not just about keeping your job or making it easier; it’s about having a say in how technology evolves and how it impacts society.
通过阅读本书,你已经展现出你的前瞻性思维。现在,我鼓励你将这种前瞻性思维付诸实践。你编写的每一行人工智能代码,你设计的每一个提示,你指导的每一位同事,你影响的每一项政策——所有这些都将为“氛围编码”的未来做出贡献。
By reading this book, you’ve shown you’re a forward-thinking person. Now, I encourage you to take that forward thinking and put it into action. Every line of code you write with AI, every prompt you engineer, every colleague you teach, every policy you influence—it all contributes to the future of vibe coding.
最后,请记住,编程的本质始终在于创造和解决问题。人工智能驱动的Vibe编程是一种极其强大的全新创作媒介。请以乐观和好奇的心态拥抱它,用它创造真正有意义的事物。同时,请始终将人的因素——我们的创造力、判断力和价值观——置于核心地位。
In closing, remember that at its heart, coding has always been about creation and solving problems. Vibe coding, powered by AI, is an incredibly powerful new medium for creation. Embrace it with optimism and curiosity. Use it to build things that matter. And as you do, keep the human element at the center—our creativity, our judgment, our values.
编程的未来正在书写,这不仅体现在代码中,更体现在我们如何选择将这些人工智能伙伴融入到我们的工作中。这是一条激动人心、充满未知的道路,我们每个人都有机会成为开拓者。所以,勇敢前行,大胆尝试,畅所欲言,以人类最卓越的智慧和精神引领未来。如此,你不仅是在适应未来,更是在积极塑造未来。
The future of programming is being written right now, not just in code but in how we choose to integrate these AI partners into our work. It’s an exciting, uncharted path, and each of us gets to be a pioneer. So step forward, experiment boldly, share freely, and lead with the best of human intellect and spirit. By doing so, you won’t just be adapting to the future—you’ll be actively shaping it.
祝你编程愉快,期待在你参与创造的未来与你再次相见!
Happy vibe coding, and I’ll see you in the future you help create!
《超越振动编码》封面上的鸟类是红腹壁雀(学名: Tichodroma muraria),这种鸟类原产于欧洲、中东和亚洲的内陆悬崖和山峰。据说,红腹壁雀飞行时看起来像大型蝴蝶,但静止在岩壁上时却很难被发现。它们的翅膀呈鲜艳的红色,羽尖为黑白相间,身体则主要呈蓝灰色。繁殖期的雄性颈部呈黑色。
The birds on the cover of Beyond Vibe Coding are wallcreepers (Tichodroma muraria), a species native to inland cliffs and mountain peaks across Europe, the Middle East, and Asia. In flight, wallcreepers are said to look like large butterflies, but they are difficult to spot at rest against rock faces. The wings have rich red coloring with black and white feather tips, while the bodies are mostly blue-gray. Breeding males have black necks.
成年壁虎体长约6英寸,体重约0.6盎司。它们每年只繁殖一窝,每次产卵3至5枚,巢穴由苔藓和草构成,呈杯状,嵌在岩石缝隙中。它们以昆虫为食。
Adult wallcreepers are about 6 inches long and weigh about 0.6 ounces. They raise a single brood each year, laying clutches of three to five eggs in cup nests of moss and grasses wedged into rock crevices. They are insectivores.
世界自然保护联盟濒危物种红色名录将攀岩墙鸟的保护级别列为“无危”。奥莱利摄影集封面上的许多动物都濒临灭绝;它们对世界都至关重要。
The IUCN Red List of Threatened Species lists the wallcreeper’s conservation status as “Least Concern.” Many of the animals on O’Reilly covers are endangered; all of them are important to the world.
封面插图由 José Marzan Jr. 绘制,取材于Lydekker 的《皇家自然史》中的一幅古老线条版画。系列设计由 Edie Freedman、Ellie Volckhausen 和 Karen Montgomery 共同完成。封面字体为 Gilroy Semibold 和 Guardian Sans。正文字体为 Adobe Minion Pro;标题字体为 Adobe Myriad Condensed;代码字体为 Dalton Maag 的 Ubuntu Mono。
The cover illustration is by José Marzan Jr., based on an antique line engraving from Lydekker’s Royal Natural History. The series design is by Edie Freedman, Ellie Volckhausen, and Karen Montgomery. The cover fonts are Gilroy Semibold and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag’s Ubuntu Mono.